First Koinos Governance Proposal Applied!
Today, Koinos received its first fork-less upgrade approved by decentralized governance, which improved the blockchain without any disruption or downtime whatsoever. In fact, most people probably didn’t even realize the upgrade happened!
On most other blockchains making this kind of change would have required months, possibly even years, of preparation to execute a restart of the network with a hard fork. These opaque, and highly political processes slow the evolution of blockchain to a crawl while introducing a centralization vector by obscuring the people behind all the decision-making. Hard forks are also highly disruptive to exchanges who need to disable withdrawals and deposits leading up to the event as they upgrade their nodes and wait for a hard fork to be applied. None of this is necessary on Koinos, freeing the protocol to improve at a more rapid rate than any other blockchain.
Koinos’ fork-less and modular upgradeability doesn’t just mean upgrades happen faster and with less disruption, but they also leave an on-chain record delivering complete transparency of when the upgrade was applied, who voted for it, and what the upgrade actually is. This was accomplished by being the first blockchain ever to have all of its system logic written as upgradable smart contracts.
The Proposal
The proposal accomplishes the following goals:
1) Further enhanced support for Smart Wallets on chain
2) Prepares the Koinos blockchain for the “approvals” feature, similar to Ethereum, to make interacting with smart contracts more secure.
3) Further enhance account abstraction for more ease of use and a better Web2-like experience in Web3.
This proposal was entirely developed and submitted by the Koinos community with developer Julian Gonzalez leading the development rather than a centralized organization.
Why does this improve Koinos?
Koinos was designed to onboard the masses by removing all friction but we also want to protect those people and that’s what this upgrade is all about. By uploading smart contract wallets (“smart wallets”) to accounts, developers can give users more fine-grained controls over their accounts, enabling them to better protect their assets. But this leaves “normal accounts” lacking in that same protection, so we want to give developers a way to check whether or not an account is protected by a smart wallet so that they can better protect users with normal accounts. That way everyone is protected.
The Details
This new system call is called get_contract_metadata and it is used to classify addresses by types: normal wallets / smart contract wallets.
Right now Koinos has 2 token standards:
KCS-1: Used in the KOIN and VHP contracts, this standard was designed to support smart contract wallets but exposes accounts to a scenario that can result in tokens being transferred without explicit confirmation from the user.
KCS-2: This token standard is for NFT’s but also introduces allowances like those in the ERC-20 contracts from Ethereum. Thanks to this improvement, the normal wallets are more protected. However, this standard does not take into account smart contract wallets. They do not support the authorize function. This token standard is available here: https://github.com/koinos/koinos-contract-standards/blob/master/KCSs/kcs-2.md
The new `get_contract_metadata` system call will allow us to create a new token standard (likely KCS-3) that is the best of both worlds: allowances to protect normal accounts, and support of the authorize function for smart contract wallets.
Onchain Technical Details
Governance Proposal
The proposal was submitted to Koinos mainnet in the following transaction:
https://koinosblocks.com/tx/0x1220b8715851c58bd757995bb700347186de21e6fbfe6b16e1b8ea546bcaacf6ef34
The proposal was applied in this block: https://koinosblocks.com/block/12979357
As it’s not easy to see the functions on a block explorer, here’s a description of the methods that were included in the proposal:
```
{
operations: [
// set new contract as system contract
{
set_system_contract: {
contract_id: “1C7JtWik7fTDD5r6B8n1HsU26s5M9qYp7i”,
system_contract: true
}
},
// assign the ID 112 to this new contract
// and define the entry point of the contract
{
set_system_call: {
call_id: 112,
target: {
system_call_bundle: {
contract_id: “1C7JtWik7fTDD5r6B8n1HsU26s5M9qYp7i”,
entry_point: 2018486792
}
}
}
},
// create a new record in the name-service contract:
// link the new contract with the name get_contract_metadata
{
call_contract: {
contract_id: “19WxDJ9Kcvx4VqQFkpwVmwVEy1hMuwXtQE”,
args: {
name: “set_record”,
args: {
name: “get_contract_metadata”,
address: “1C7JtWik7fTDD5r6B8n1HsU26s5M9qYp7i”
}
}
}
}
],
operation_merkle_root: “…”,
// fee required to submit this proposal
fee: “4000000000”,
}
```
The new contract is `1C7JtWik7fTDD5r6B8n1HsU26s5M9qYp7i`. There is also a nickname for the contract here: https://koinosbox.com/nicknames/@get-contract-metadata.
That contract was uploaded in the transaction https://koinosblocks.com/tx/0x1220af4322873a2e669d0d313c4d7ccb5c2a7f82b82b7d93b4457fafc468a1aecd79 and it has the following properties:
```
sha-256: “7e4192b4a84103dbc4de674a730a49b9028b56f54a99424311de7457ab74467f”,
authorizes_call_contract: true,
authorizes_transaction_application: true,
authorizes_upload_contract: true
```
This means the contract is immutable and the original developer no longer has control of the contract. The sha-256 checksum can be verified by compiling the code of the commit: `9e1437` with koinos-sdk-as-cli v0.1.16.
More technical details can be found in these posts from developer Julian Gonzalez:
https://peakd.com/koinos/@jga/improve-security-koinos
https://peakd.com/koinos/@jga/check-authority-2-testnet
https://peakd.com/koinos/@jga/new-koinos-system-call-live-in-the-testnet
https://peakd.com/koinos/@jga/gov-proposal-get-contract-metadata
Article Author: Justin Welch / Julian Gonzalez / Rhubarb Media / Andrew Levine
