Open Isaac-DeFrain opened 3 years ago
After some attempts at trying the solutions above, the current solution seems to be an OK temporary solution for now because we don't have too many libraries to look into and we don't have too many rholang developers who have real contracts on-chain and the developers use the library in the wrong way.
However, there are still great limits and difficulties(dependency hell would happen).
The more perfect way to is have a build system which could help on building rholang like sbt, yarn and even babel-like tools to generate linking rholang.
RChain blessed contract upgrades (i.e. soft-fork mechanism)
Contract standard
TreeHashMap
to store contract uris, we will need to make this uri map available for peeksa
and one with unforgeable nameb
, we make themcontract unf(@"a", ...) = {...}
andcontract unf(@"b", ...) = {...}
, respectively, for some fixed unforgeable nameunf
unf
Dynamic dispatch
Each system (blessed) contract will exist as data on a fixed location channel corresponding to the contract. E.g. if
C
is a blessed contract, then we add a level of indirection through dynamic dispatch byThe
cLoction
channel will be accessible only through a multisig contract in the registry which the coop will have keys to. This indirection buys us the flexibility to update a contract by simply extracting all state elements from the old contract, initializing the new contract's state elements with them, and updating the data stored on the location channel through a quorum of multisig public key agreements.In the registry uri map, instead of directly mapping a blessed contract's shorthand to the contract's uri, we map the shorthand to a dispatcher contract which gets the data from the corresponding location channel and calls that contract with the supplied arguments. E.g. if
C
is a blessed contract, then it will have an accompanying dispatcher contract to dispatch callsPreviously, when we added this contract to the registry, we simply did an
insertSigned
withbundle+{*C}
. Now, we will do aninsertSigned
withbundle+{*cDispatcher}
. Hence, the registry uri map will contain the keyrho:registry:c
(for example) and value(max_int, bundle+{*cDispatcher})
.Requiring all methods in a blessed contract to be of the form
for a fixed unforgeable name
contractName
, will make it so that we only need to managecontractName
. All method calls will be dispatched in the same way.Location channels
The channels which serve as a protected store for blessed contract data will be generated as unforgeable names in the original instance of the corresponding contract. In this original instance, the location channels will be passed to the multisig contract for further management via
insertBlessed
. CallinginsertBlessed
simply updates theblessedContractLocationMap
which the multisig controls. There is oneinsertBlessed
consume for each blessed contract to prevent any other contracts from being added.MultiSig
The multisig contract is declared in the registry and gives privileged access to
propose
,agree
, andupdate
methods. This contract is used to manage the data stored on the blessed contract location channels. The methodspropose
: allows any of the privileged public keys to propose new data(con, meth)
to store on a blessed contract location channel (i.e. an update) wherecon
is the unforgeable name of the new contract andmeth
is the unforgeable name for the new contract's methodspropose(@pubKey, @uri, @con, @meth, @sig, ret)
agree
: allows the privileged public keys to "agree" with a proposalagree(@pubKey, @uri, @con, @meth, @sig, ret)
update
: once there is a quorum of privileged keys agreeing on a proposal, this method will update the data on the corresponding location channelupdate(@uri, ret)
Proof of Concept
Drawbacks
Extra comm events are required to interact with the affected contracts.