Research tendermint-rs

[junha1]

Research tendermint-rs

[yeomjh00]

1. Tendermint-rs Conditions

1. 1. No need for slashing conditions. (No strong accountability needed)

   ⇒ Tendermint supports ‘evidence’ for slashing. we can choose whether slash or not.

2. Instant (one-block) finalization.

   ⇒ Tendermint supports it. https://tendermint.com/core/

3. On-demand block production. (No empty blocks)

   There exists an option for on-demand block production.

   By setting ‘create_empty_block=false’ in default configuration file created by tendermint_init, we can meet On-demand block production.
   https://docs.tendermint.com/master/nodes/configuration.html

4. Consensus-level yes-or-no choice (This becomes trivial for an asynchronous consensus, as voting for 'reject' equals to the case in the asynchrony, where a node pretends that he's missing the block proposal (which, in fact, he dislikes) because of the network asynchrony.)

   ⇒ O

5. Fair chances of block-proposing right are NOT required. (stable leader is OK, and actually desired)

   ⇒ Tendermint uses weighted round-robin for proposal sequence. But it does not mean stable leader. following links are explanation for round-robin system for Tendermint.

   tendermint docs: https://docs.tendermint.com/master/spec/consensus/proposer-selection.html#r2-fairness

   한글 설명 버전: [https://medium.com/cosmonauts-in-korea/텐더민트의-view-change-방법을-알아보자-aa07b736126d](https://medium.com/cosmonauts-in-korea/%ED%85%90%EB%8D%94%EB%AF%BC%ED%8A%B8%EC%9D%98-view-change-%EB%B0%A9%EB%B2%95%EC%9D%84-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90-aa07b736126d)

6. BFT threshold 1/3 is allowed to become smaller.

   ⇒ O

7. Synchrony assumptions is also OK to take.

   Tendermint assume partial synchrony of the network.

   https://tendermint.com/static/docs/tendermint.pdf

8. There MUST be a support for the light client verification. (i.e., it must be based on cryptography, not some live observation protocol)

   ⇒ Tendermint supports light client verification. it is based on cryptography using Bisection algorithm and cross check.(verified using merkle root)

   Sequential Verification → Bisection Algorithm(Skipping Verification) + cross checks

   https://medium.com/tendermint/everything-you-need-to-know-about-the-tendermint-light-client-f80d03856f98

---

2. How tendermint abstracted Network?

Tendermint

Message, Channel을 사용

proposal이나, vote를 하게 될 경우, 그에 대한 parameter를 protobuf를 사용하여 변환한다음 Message로 소통. proposal, signedproposal, Vote…etc 모두 Message형식으로 바꿈

그리고 각각의 따로 채널을 두어서 메세지를 구분한다.

GRCP를 사용하여 p2p network를 사용하는 것 같은데, 자세하게는 알지 못한다.

Our job

libp2p?

---

3. Summary of Final Interface

Architecture of Tendermint

ref: https://salemal.medium.com/a-paper-review-the-design-architecture-and-performance-of-the-tendermint-blockchain-network-7402e0179bd4

ABCI ⇒ broadcasting in mempool, consensus, queries of application

ref(eng): https://docs.tendermint.com/master/introduction/what-is-tendermint.html

ref(kor): https://comnic.tistory.com/43

More about ABCI

현재, synchronous, blocking API만 제공한다. async client/server는 후에 지원될 예정

“Request, Response” message type을 사용해서 SMR을 사용

Request, Response → [Consensus, Mempool, Snapshot, Info, Flush]

→ ABCI

• apply_snap_shot_chunk

  • Applies a snapshot chunk.
  • Returns the result of applying a snapshot chunk and associated data.

• begin_block

  • Signals the beginning of a new block.
  • Returns events that occurred when beginning a new block.

• check_tx

  • Check whether a transaction should be included in the mempool.
  • Returns the result of checking a transaction for mempool inclusion.

• commit

  • Signals the application that it can write the queued state transitions
  • Returns the result of persisting the application state.

• deliver_tx

  • Execute a transaction against the application state.

  Returns events that occurred while executing a transaction against the application state.

• echo

  • Echoes a string to test an ABCI implementation.
  • Echoes a string to test an ABCI implementation.

• end_block

  • Signals the end of a block.
  • Returns validator updates that occur after the end of a block.

• flush

  • Indicates that any pending requests should be completed and their responses flushed.
  • Indicates that all pending requests have been completed with their responses flushed.

• info

  • Requests information about the application state.
  • Returns information about the application state.

• init_chain

  • Called on genesis to initialize chain state.
  • Returned on genesis after initializing chain state.

• list_snapshots

  • Asks the application for a list of snapshots.
  • Returns a list of local state snapshots.

• load_snapshot_chunk

  • Used during state sync to retrieve snapshot chunks from peers.
  • Returns a snapshot chunk from the application.

• offer_snapshot

  • Offers a list of snapshots to the application.
  • Returns the application's response to a snapshot offer.

• query

  • Queries for data from the application at current or past height.
  • Returns data queried from the application.

+) exception (response only!)

• Returns an exception (undocumented, nondeterministic).

tendermint-rs docs for abci: https://github.com/informalsystems/tendermint-rs/tree/master/tendermint/src/abci/doc

tendermint official docs: https://docs.tendermint.com/master/spec/abci/apps.html

---

4. What can and cannot be customize

1. Tendermint-rs Conditions

   On-demand block finalization

2. How tendermint abstracted Network

   docs에서는 GCRP를 주로 사용하는데 반해, 현wo libp2p가 자주 나오는 것으로 보아, 이는 따로 핸들링해야할듯 하다.

3. Summary of Final Interface

   새로 만들고 싶은 프로토콜 추가 구현해서, 연관된 crate(abci, prot-abci …etc)에 추가해주면 될 것 같음

[junha1]

1. Data Types
2. Header definition
3. Prevent-empty-block handling
4. Tests
5. Network interface
6. Subprotocols (Sync?)

[junha1]

Concluded that it's too complicated, costly to understand, and not so applicable for our case.