88 lines
3.4 KiB
Markdown
88 lines
3.4 KiB
Markdown
|
#### smart contract code mgmt
|
||
|
|
|
||
|
|
each contract is registered in the database and has following properties:
|
||
|
|
|
||
|
|
- contract_address = unique id, cannot be changed
|
||
|
|
- contract_hash = the latest code for this contract (is a hash of the sorted directory, so everyone can check)
|
||
|
|
- contract_link = where can the code be found
|
||
|
|
- upgrade_multisig_accounts e.g. 9 accounts need to sign for an upgrade of the code
|
||
|
|
- upgrade_multisig_min_signature e.g. 6 need to sign
|
||
|
|
|
||
|
|
### Example Record
|
||
|
|
|
||
|
|
```json
|
||
|
|
{
|
||
|
|
"smart_contract_code_mgmt": {
|
||
|
|
"contract_address": "0x1234567890123456789012345678901234567890",
|
||
|
|
"contract_hash": "0xabcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890",
|
||
|
|
"contract_link": "https://github.com/freeflowuniverse/mysmartcontract/src",
|
||
|
|
"upgrade_multisig_accounts": [
|
||
|
|
"0x1111111111111111111111111111111111111111",
|
||
|
|
"0x2222222222222222222222222222222222222222",
|
||
|
|
"0x3333333333333333333333333333333333333333",
|
||
|
|
"0x4444444444444444444444444444444444444444",
|
||
|
|
"0x5555555555555555555555555555555555555555",
|
||
|
|
"0x6666666666666666666666666666666666666666",
|
||
|
|
"0x7777777777777777777777777777777777777777",
|
||
|
|
"0x8888888888888888888888888888888888888888",
|
||
|
|
"0x9999999999999999999999999999999999999999"
|
||
|
|
],
|
||
|
|
"upgrade_multisig_min_signature": 6
|
||
|
|
}
|
||
|
|
}
|
||
|
|
```
|
||
|
|
|
||
|
|
How does it work
|
||
|
|
|
||
|
|
- someone asks for upgrade e.g. location can have a branch inside
|
||
|
|
- the hash needs to be specified
|
||
|
|
- the upgraders will get a request to look at the code
|
||
|
|
- once the code is audited and approved they will sign the upgrade transaction
|
||
|
|
- once majority is achieved the record will be changed to show the new location & hash
|
||
|
|
- now the execution engines in the field (the validators of the blockchain) will see there is new code, they will build the code themselves, verify the hash, if all ok then the new code will be used, otherwise the smart contract will stop to operate
|
||
|
|
|
||
|
|
## implementation detail
|
||
|
|
|
||
|
|
```mermaid
|
||
|
|
sequenceDiagram
|
||
|
|
participant Proposer
|
||
|
|
participant UpgradeSystem
|
||
|
|
participant MultisigAccounts
|
||
|
|
participant BlockchainDB
|
||
|
|
participant Validators
|
||
|
|
|
||
|
|
Proposer->>UpgradeSystem: Propose upgrade (new hash & location)
|
||
|
|
UpgradeSystem->>BlockchainDB: Retrieve current contract info
|
||
|
|
BlockchainDB-->>UpgradeSystem: Return contract info
|
||
|
|
|
||
|
|
UpgradeSystem->>MultisigAccounts: Notify of upgrade request
|
||
|
|
|
||
|
|
loop Until upgrade_multisig_min_signature reached or all reviewed
|
||
|
|
MultisigAccounts->>MultisigAccounts: Review and audit new code
|
||
|
|
alt Code approved
|
||
|
|
MultisigAccounts->>UpgradeSystem: Sign upgrade transaction
|
||
|
|
else Code rejected
|
||
|
|
MultisigAccounts->>UpgradeSystem: Reject upgrade
|
||
|
|
end
|
||
|
|
end
|
||
|
|
|
||
|
|
alt Sufficient signatures collected
|
||
|
|
UpgradeSystem->>BlockchainDB: Update contract record (new hash & link)
|
||
|
|
BlockchainDB-->>UpgradeSystem: Confirm update
|
||
|
|
UpgradeSystem->>Validators: Notify of contract update
|
||
|
|
|
||
|
|
loop For each Validator
|
||
|
|
Validators->>Validators: Fetch and build new code
|
||
|
|
Validators->>Validators: Verify code hash
|
||
|
|
alt Hash verified
|
||
|
|
Validators->>Validators: Deploy new code
|
||
|
|
else Hash mismatch
|
||
|
|
Validators->>Validators: Stop contract operation
|
||
|
|
end
|
||
|
|
end
|
||
|
|
|
||
|
|
UpgradeSystem->>Proposer: Notify upgrade success
|
||
|
|
else Insufficient signatures or rejected
|
||
|
|
UpgradeSystem->>Proposer: Notify upgrade failure
|
||
|
|
end
|
||
|
|
```
|