What are Privileged Contracts?

Behind the Scenes with Tgrade and PoE

Photo by Danny Howe on Unsplash

We, the creator of CosmWasm and Proof of Engagement consensus, are now in the process of finalizing a regulatory-friendly blockchain Tgrade, leveraging and combining these two. Now, with upcoming Tgrade code being open-sourced, this article demonstrates how much work we have done, why it matters, and why Proof of Engagement is technically good from developer’s point of view.

As part of building Tgrade, we also built our own consensus protocol, Proof Of Engagement. (This warrants a few articles on its own…). And naturally, as the creators of CosmWasm, we wondered if we could build this as a network of smart contracts. In wasmd, smart contracts are sandboxed by design, meaning they cannot take any action that an external user cannot. They are a special kind of account managed by code.

We saw more potential, to break this constraint and allow chain governance to empower certain system critical contracts to a privileged status. This would potentially allow them to integrate deep with the platform running them. For example get a callback on every begin or end block, update the validator set, mint arbitrary tokens, change block gas/byte limits, or execute governance proposals (the “super user” messages used internally in the Cosmos-SDK that powers the Cosmos hub and all Cosmos based blockchains).

We knew this didn’t belong as part of the standard wasmd library, but we also didn’t want to fork it, but rather import it as a library (and serve as an example of how to extend without forking). During this process, we added several extension points to wasmd to customize handlers, expose “sudo” callbacks, and take interfaces in many places rather than structs.

Enter TWasm

The end result of all this is twasm, short for “Tgrade Wasm” or “Trusted Wasm”. This imports x/wasm and provides special entry points for handling privileged contracts. This is the foundation of Tgrade and PoE. The code will be open in a few weeks when we open source Tgrade, but here is an overview:

Promotion — Before a contract can take any privileged action, it must be “promoted”. This can be performed by on-chain governance, or by any other contract previously granted this privilege. When a contract is promoted, it can request privileges and activate features. Contracts may start in a “dormant” state after instantiate and only allow message execution after they have been promoted and granted the required privileges.

Privileges — We have defined a number of special message types that can only be executed by contracts that have been granted the corresponding privilege. Note that currently a promoted contract will be approved for any RequestPrivilege message, but the API leaves it open to only grant some of these privileges in the future. Once the contract has the privilege, some messages are:

• MintTokens — any number of any native token, including the staking token
• WasmSudo — call sudo on any other contract
• GovProposal — execute most “governance proposals” in the SDK, including promoting other contracts
• ConsensusParams — Update Tendermint consensus params, like max block gas and block bytes.

Callbacks — Besides these messages, the promoted contract can register for a callback to happen every block. The options are:

• BeginBlock — Called on every BeginBlock along with the Tendermint misbehavior evidence (double signing), if any
• EndBlock — Called on every EndBlock, but cannot adjust the validator set
• EndWithValidatorUpdate — Only one contract may register for this at a time. It will be called on EndBlock and can return a diff to the validator set, allowing it to implement PoS, PoA, or any other consensus algorithm.

Contract Extension — In order to store this information along with the contract, we make use of the optional Extension field in ContractInfo from x/wasm. Here we store a list of privileges that the contract has and whether it has been promoted. It also serves as an example for any other module that wishes to add custom info to the ContractInfo without forking wasmd .

Is this Safe?

The first concern most people have with this is about security. How can you give a contract root access to the chain?

However, it is not like anyone can upload code that gets root access to the SDK. Each contract must be promoted by on-chain governance first, which should do a security review. On-chain governance can also request an upgrade of the Go binary, which can contain arbitrary code, so this is no more dangerous.

In fact, I would say this is safer, as the contract has very clear entry points, and must explicitly request privileges, making it easier to audit which actions it may or may not take. If you see some contract that only needs BeginBlock, but also requests TokenMinter, it will quickly raise a red flag.

What can you build?

The first use case in Tgrade was to update the validator set with PoE, using a mix of Engagement and Stake to derive Authority.

We also make heavy use of BeginBlock to do things like auto-return tokens after the unbonding period, as used in the native Go modules. This is a great usability enhancement from unprivileged cw-plus contracts, which require a separate “Claim” call by the user once the unbonding period has passed.

Imagine a subscription service. You can register on BeginBlock and charge other contracts a fee to cover the gas, then perform a reoccuring action when the time comes.

You can use all the power and flexibility of cw3 contracts (DAOs) and delegate parts of chain governance to them. That means we don’t need to have one monolith x/gov with all power, and deeply tied to the PoS model, but you could write a contract that just allows Pin/UnpinCode proposals and assign a small DAO that power, to quickly tune the chain performance.

And note that all of these functions can be provided by CosmWasm contracts, so you can upload a new Wasm contract and the on-chain governance, as “admin” of the contract, can migrate the contract and update the functionality of core components without a chain upgrade and replacing the binary. This is one of Substrate’s defining characteristics, and is now available in Cosmos SDK chains!

Interested?

Are you now convinced that how solid the Tgrade codes are? Do you want to see it for yourself, get inspired, and start building? You will be able to do so when the Tgrade source code goes open-sourced shortly under an Apache license. Until then, stay in touch.

Follow us on Twitter, Medium, and LinkedIn, visit our website, or join our Discord to get informed of any updates.