Page Comparison

...

The scope of this proposal intended to be limited to the software responsible for the Casper consensus, as well as those system-wide contracts that are critical to how the RChain blockchain functions (such as the REV Vault contract).)

For Casper, this means any software that changes the casper block protoCasper BlockMessage protobuf:

• Rholang interpreter
  • Tuplespace output As Tuplespace's trie's resulting state hash would change
• RSpace event log
• Every other field in the block protoRSpace Event logthe BlockMessage protobuf

Blessed Contracts

I'm not sure if the term "Blessed Contract" is officially defined anywhere, but for this document, the term Blessed Contract implies those contracts which are part of the RChain node software that is required to enforce the consensus protocol and otherwise ensure the proper functioning of the RChain blockchain.  I further intend to use this proposal to more formally codify the term Blessed Contract as those Rholang contracts that, like the scala Scala node software, maintain the correct state of the blockchain based on the protocol rules that have been established through social (off-chain) means. The difference between Blessed Contracts and other node software is that the rholang pars are actually stored in the tuple space.

Background

There are a set of blessed contracts that implement the core functions of RChain. A few of these core functions handle the consensus protocol ( such as PoS.rho ) while others provide the base system functionality such as RevVault.rho, which does REV management (receive/spend).

Currently, these system these blessed contracts are stored in the registry along with other user contracts using insertSigned. The registry itself is technically a system process, not a blessed contract. To learn more about what a system process is, you can read about it ADDLINK. The inputs into insertSigned are the Public public key, nonce, channel, and signature over those parameters. The results in a unique URI for the entry in the registry based on the public key used in the insert, and the signature guarantees that only the owner of the public key could perform the insert.

One cumbersome outcome of this approach is that each blessed contract that is added to the registry uses a unique key pair. I don't believe this is technically necessary in that the same keypair could be used so long as the channel being added were unique for each insert. Furthermore, because the blessed contracts are stored in this registry, it is necessary to manage all the private keys used to generate the signature used in the insertSigned call. Currently the nonce used for system contracts is set to maxLong to prevent it from ever being updated.  Using insertSigned for "Blessed Contracts" blessed contracts does not currently allow contracts to be updated without resulting t???

With this current approach there are only two ways to update these blessed contracts. One is to :

1) We can modify the code to use a nonce starting at zero, so we could update the entries with follow-on inserts. The problem with this approach is that if the private keys for these contracts ever fell into the wrong hands, anyone could deploy code to update these contracts.

A second approach could be to 2) Or we can insert new blessed contracts using new keypairs resulting in a new URI. I mention this approach for completeness, but in practice, this would be horrible as it would require all Rholang that references these previous URIs to be updated.

...

We add a new system process called insertBlessed("contract name", channel). This call would only be available to the node software via a scala Scala interface but would add the contract name it the global registry (thus updating the tuple space). A call to insertBlessed with a contract name that is already registered will overwrite the previous name with the new channel.

...

With such an approach, updating the blessed contracts would occur in scala Scala code as follows:

private def bondsQuerySource(name: String = "__SCALA__", blockHeight: Long = 0): String =
if (blockHeight == UPGRADE_BLOCK_NUMBER) {
   insertBlessed("PoS", new_channel) // assume new_channel was result of adding new PoS.rho to tuplespace
}

...