Support inheritance exception based on proof of ownership

[samuelmanzanera]

Is your feature request related to a problem?

Smart contracts need a way to be able to escape inherit constraints by proving you are the owner of the contract or being authorized in a specific list of owners.

Because the smart contract's keys must be shared with the nodes to allow self-triggers of transactions, we cannot rely afterward on the chain's private keys to prove the ownership.

The #47 introduced a way to support with custom key-derivation scheme, we would like to avoid a new key derivation scheme just for this purpose.

Describe the solution you'd like

To do so, we have to rely on knowledge capability of the owner to determine the eligibility.

Definition

On the SDKs side, once a new smart contract will be created, the SDK should propose to add a new random secret with a list of authorized public keys. So, it will add an inherit constraint to add proof of ownership verification.

This operation will a block like this one:

condition inherit: [
   exception: Crypto.verify?(transaction.content, contract.code, 0x0e312ff....)

   # Or a shorter way which the verification will be implicit
   exception_key: 0x0e312ff....
]

Authorization

To achieve a key authorization scheme with renewal of authorization, the idea is to leverage random keys for each new authorized public key. Hence, the key generated will change and will help to determine the public key associated with the usual key derivation scheme

Verification

Later, when the owner of the contract would like to bypass inherit constraints to update the code, the user would have to send the new smart contract code, with the signature of the contract using the ownership's key. The nodes would have to check if the inherit's condition is defined and if the execution of the condition returns true. This operation will check the exception_key or exception instruction.

By default, the inherit constraints exception should be false.

Additional context

--

This refers to the AEIP22

Epic

#608

[samuelmanzanera]

We might also have a mechanism to support an external approval from another chain. For instance, we might have a chain dedicated to the governance of dApp or multi sig chain hence, only the external chain can modify the code. In that sense, the inherit might not be necessary and the condition transaction could regulate the update of the code. (cf @Neylix )

condition transaction: [
   content: Json.valid?,
   code: Chain.get_genesis_address(transaction.address) == 0x0f12321......
]

actions triggered_by: transaction do
   [action: action code: new_code] = Json.parse(transaction.content)
   if action == "update" do
      Contract.set_code(new_code)
   end
end

[samuelmanzanera]

I'm wondering if we should provide a kind of behavior/abstraction to support it by default and hide the logic with the

condition inherit: [
   exception_key: 0x0f12321.....
]

[samuelmanzanera]

Requires #1156

[Neylix]

Is this issue still relevant ? I guess we have an actual behavior to handle ownership which is similar to other blockchain and could be more decentralized.