Safety and Liveliness

The safety and liveliness properties of a system define the properties that the system can (a) guarantee are always true, and (b) guarantee are eventually true. Understanding these properties is fundamental to understanding the limitations of a system.

The Tendermint consensus algorithm describes its own safety and liveliness properties. In this chapter we show that RenVM does not change these safety and liveliness properties, and we reason about the new safety and liveliness properties that RenVM introduces.

Safety

RenVM does not modify the fundamentals of the Tendermint consensus algorithm, ensuring that the existing safety properties are maintained:

  • Proposing a block is modified to include pseudo-transaction. This modification is only a requirement to include specific data in a block.

  • Voting is modified to check the validity of pseudo-transactions in a proposed block. This modification only reduces the number of valid blocks, because it does not remove existing validity checks.

  • Committing is unmodified.

RenVM introduces new safety properties in addition to those guaranteed by the Tendermint consensus algorithm:

  • Secret data in a transaction is never revealed to anyone other than the person that built the transaction.

  • Secret state in a contract is never revealed to anyone, unless explicitly specified in the business logic of the contract.

Ensuring these safety properties is done by the RZL sMPC algorithm. The RZL sMPC algorithm requires 1/3rd+ colluding adversaries to open secret data. The Tendermint consensus algorithm cannot guarantee safety properties at 1/3rd+ adversaries and so the introduction of these new safety properties, guaranteed by RZL sMPC, does not reduce the safety threshold.

Liveliness

RenVM does not modify the fundamentals of the Tendermint consensus algorithm, ensuring that the existing liveliness properties are maintained:

  • Proposing a block is modified to include pseudo-transaction. The building of pseudo-transactions is an asynchronous process that only requires participation from 1/3rd+ Darknodes. Assuming that 1/3rd+ Darknodes are online and non-adversarial, pseudo-transactions can be built and included in proposed blocks.

  • Voting is modified to check the validity of pseudo-transactions in a proposed block. In the case of invalid block proposals, the Tendermint consensus algorithm is able to progress to a new round where a new proposer will propose a block. Assuming that 1/3rd+ Darknodes are online and non-adversarial, pseudo-transaction can be built and included in proposed blocks. Therefore, eventually, an honest proposer will selected that has access to valid pseudo-transactions.

  • Committing is unmodified.

  • Executing the transactions in a block requires 2/3rd+ Darknodes to be online and non-adversarial. Attempts by a malicious Darknode to execute transactions erroneously are detected using zero-knowledge proofs and can be ignored by non-adversarial Darknodes.

The Tendermint consensus algorithm can only guarantee its liveliness properties when 2/3rd+ nodes online and non-adversarial. The modifications made by RenVM also requires 2/3rd+ Darknodes to be online and non-adversarial.