Ren is powered by RenVM, a virtual machine that replicates itself over a decentralised network of thousands of machines. It run instructions and replicates state by leveraging the computational, storage, and network resources of these underlying machines. But what makes RenVM unique is that it does all of this in complete secrecy. The state and IO of all processes is kept hidden from everyone, even the machines that power RenVM.
RenVM is designed and developed under three guiding principles:
RenVM cannot be controlled or censored by a central authority. Anyone can invoke the instructions built into the virtual machine, anyone can deploy their own scripts, and anyone can contribute their resources to power the virtual machine in exchange for fair compensation.
Byzantine Fault Tolerance
RenVM is designed to be trustless. It is design to guarantee its safety and liveliness properties even in the presence of malicious participants. Unless 1/3rd+ of participants are maliciously colluding, instructions are guaranteed to run correctly and their inputs, ouptuts, and state are guaranteed to be kept secret.
RenVM is resilient to failures of the underlying machines. Faults in less than 1/3rd+ of the machines cannot cause loss of data. Similarly, such failures will not prevent instructions from running correctly. This liveliness ensures that RenVM can make progress even when machines are offline or unavailable.
RenVM uses a modified version of the Tendermint consensus algorithm to achieve Byzantine fault tolerant consensus between machines. This consensus algorithm allows the machines that power RenVM to quickly agree on which messages to handle, and in what sequence, even when some of the machines are unavailable or behaving maliciously.
Messages are handled using a secure multiparty computation algorithm. This allows RenVM to handle messages in secret, not revealing the inputs/outputs/states to anyone, not even the machines powering RenVM. The algorithm has the same safety and liveliness properties as the Tendermint consensus algorithm, making these two algorithms a natural marriage for each other, and ensuring that RenVM is always secure and always running.
RenVM uses a secure multiparty computation algorithm that has been recently developed by the Ren team: the RZL sMPC algorithm. By using this algorithm, RenVM is able to run computations in secret: the inputs, outputs, and states of the computation are never revealed to anyone.
Secure multiparty computation is different from zero-knowledge proof systems. In zero-knowledge proof systems, someone (the prover) needs to know all of the secrets so that a proof can be generated for transitions state on a blockchain (the verifier). Although the secrets are not verifier to the blockchain, they are revealed to the prover. These kinds of zero-knowledge systems, while powerful, cannot model the same kind of computations that sMPC is able to model.
It is also different from homomorphic environments. In homomorphic environments, only one node is required to do the computation. This is effective sometimes, but it also means that computations can proceed without consensus from the entire network. This property is necessary when you only want the computation to proceed under some circumstances.
RenVM uses its secure multiparty computation capabilities to implement truly decentralised interoperability between blockchains of all kinds. Interoperability is achieved by generating a secret private key. This secret private key is used to sign events and transactions on different blockchains so that RenVM can prove events have been validated by its decentralised network of thousands of Darknodes.
The secret private key is able to accept tokens from one blockchain, and mint a representation of them on another blockchain. When the minted tokens are burned from the other blockchain, the respective tokens can be released on the original blockchain.
This approach to interoperability is more general, and more flexible than other approaches. It improves upon federated peg technique, by supporting thousands of machines even on Bitcoin (where multi-sigs are currently limited to 20 signatures). It improves upon protocol-based techniques (such as Cosmos, Polkadot, or Aion) by supporting existing blockchains that do not support the required protocol messages.
RenVM will initially support:
BTC payments to/from Ethereum smart contracts,
ZEC payments to/from Ethereum smart contracts,
USDT payments to/from Ethereum smart contracts, and
BTC/ZEC, BTC/USDT, BTC/ETH, and BTC/ERC20 trading pairs.