RenVM uses a modified version of the Tendermint consensus algorithm to achieve BFT consensus between Darknodes on blocks of transactions. After reaching consensus on a block, RenVM executes the transactions in it using RZL secure multiparty computation. This allows RenVM to keep inputs, outputs, and state transitions a secret from everyone, including the Darknodes that power RenVM.
The Tendermint consensus algorithm proceeds in block heights, where each block height commits exactly one block, and involves multiple rounds of voting. An overview of the Tendermint consensus algorithm can be found in their documentation.
Upon entering the current round, the Darknode leader will propose a block of transactions that it hopes to see committed for the current height. If the Darknode leader does not propose a valid block in time, the Tendermint consensus algorithm will guarantee that the round will be incremented and a new Darknode leader will be elected. See the Tendermint consensus algorithm for more information.
Darknode leaders are required to inject pseudo-transactions into a block before proposing it to other Darknodes. Pseudo-transactions are continuously built by the Darknodes, and are required by RZL to execute most blocks. The transactions in a block will determine the number, and type, of pseudo-transactions that must be injected.
Upon seeing a proposal for the current round, or timing out, Darknodes will broadcast a vote for the block, or a vote for no block. See the Tendermint consensus algorithm for more information.
Darknodes must verify that they have seen all pseudo-transactions in the proposed block, the pseudo-transactions are valid, and the pseudo-transactions are accompanied by the required zero-knowledge proofs of correctness. If so, block validation proceeds as usual. If not, the block is considered invalid.
Upon seeing a polka for the current round, or timing out, Darknodes will broadcast a commitment for the polka block, or a commitment for no block. See the Tendermint consensus algorithm for more information.
Upon seeing 2/3rd+ commitments for a polka block, nodes participating in a Tendermint consensus algorithm will usually execute all of the transactions in the block without further interaction with other nodes. However, in RenVM, transactions in a block must be executed using RZL secure multiparty computation. This ensures that inputs, outputs, and state transitions can be kept secret, but it also requires further interaction between nodes.
Committed blocks will be placed into a FIFO execution queue. Darknodes will progress through the execution queue and invoke an RZL secure multiparty computation for each transaction. After all transactions in the block have been executed, the block must be fused.
Fusing a block involves taking all intermediate values produces during the RZL secure multiparty computations, injecting them into the footer of the block, re-signing the entire block, and broadcasting the signature. Fusing a block can be done locally, since all intermediate values are the same for all Darknodes. After seeing 2/3rd+ signatures for the same block, with the same footer, the block is said to be fused and the next block in the execution queue can be executed.
Pseudo-transactions are required by Darknodes in order to execute the transactions in a block. The pseudo-transactions needed to execute a transaction are not correlated with the transaction, and so Darknodes are able to fill a pseudo-transaction pool in parallel with the core consensus algorithm. This reduces the impact on consensus performance.
By observing the transactions in a block, a Darknode can determine the number of pseudo-transactions required, and the type of pseudo-transactions, that are required to execute the block. This determination is non-interactive and does not require extra communication between Darknodes.
It follows that the addition of pseudo-transactions does not affect the core consensus algorithm.
RenVM does not use any of the other features that come under the more general concept of Tendermint (such as its ABCI, or Go implementation). RenVM only uses the theoretical consensus algorithm. An implementation of the consensus algorithm can be found on GitHub.