Explanation of Starcoin Contract Account

* By Starcoin community

From Ethereum's Contract Account

Compared with Bitcoin, the biggest innovation of Ethereum is the introduction of smart contracts, which give the blockchain a powerful expressive ability. And behind the smart contract is a new account model. Unlike Bitcoin's UTXO model, Ethereum uses the account model. There are two types of accounts in Ethereum, named Externally Owned Account and Contract Account. There are three main differences between these two types of accounts:

• Creation Way
• Is there any contract codes
• Can Initiate Transactions Proactively

The external account needs to be created with a private key. It is an account for general users. It can only store the balance of the current user, and no code is allowed. The user controls the account through the private key and initiates the transaction proactively, which is the entrance of general users. The contract account is calculated from data such as the Address of the external account, and can store codes. The contract account status is controlled by the contract, and can store all data generated through the contract.

These two accounts essentially aim to store the user status and contract status separately. However, with the rapid development of blockchain, Ethereum's account model faces many problems:

1. States generated by contract are getting more and bigger;
2. Users' contract data are stored under the same contract account,there are two main concerns: prone to security risks (such as large arrays),data's ownership is not clear;
3. Cannot pay by status;
4. ETH is a first-class citizen and is stored under the user Balance; ERC20 is a second-class citizen and is stored under a contract account;
5. The Context that is used to call a contract is more complicated to understand, and it is easy to cause security problems;
6. Code and status are not stored separately;

Ethereum has made many innovations in the Account model, but with the rapid development of the blockchain, many design flaws have become more and more obvious. Since the Account model can support smart contract well, Starcoin also embraced the Account model. Compared with Ethereum's Account model, Starcoin's Account model has great advantages. Inheriting the advantages of the Account model, Starcoin's account is the best remedy for the shortcomings of the Ethereum Account model.

More Advanced Account Model

In order to provide better service to most user,Starcoin's Account model has designed a Data part and a Code part. The Data part is used to store user data, and the Code part is used to store contract code, completely storing "user data" and "contract code" separately.

As Starcoin's smart contract language Move is resource-oriented programming, the resources generated by the contract can only be transferred between accounts under the protection of the Move virtual machine, and cannot be modified (modification must call the contract). Therefore, running the Move contract on the Starcoin account model has many advantages:

• The account is divided into the Data part and the Code part, and the contract is stored in the account Code part
• Any account can contain both Data and Code
• The data is distributed stored in the user's own Data part instead of centralized storage under the contract account
• Clarify the ownership of the Resource and improve security
• All Tokens (including STC) are registered through the same Token protocol and follow the same specifications
• Provides the possibility for state billing, avoiding "state explosion"
• Separate the state from the code, so that the contract call has a clear context

Starcoin's Contract Account

We have compared Starcoin's account model and Ethereum's account model,it can be said that Starcoin has a more advanced account model. Any Starcoin's account can store Data and Code at the same time, covering all scenarios of Ethereum. In order to expand more application scenarios, Starcoin also designed contract accounts, so Starcoin also includes external accounts (Externally Owned Account) and contract accounts (Contract Account) like Ethereum. However, Starcoin contract accounts are very different from Ethereum contract accounts. Next, we will introduce Starcoin's contract account in depth from the following aspects.

Starcoin's contract account

Because of the different design goals, Starcoin contract accounts are very different from Ethereum contract accounts. Starcoin contract accounts have the following characteristics:

• Starcoin's contract account essentially host the signature authority . Except for the authority to sign, other aspects are exactly the same as those of Starcoin's external account
• The account implementation of Starcoin is unified, and the contract account and the external account can be converted to each other.
• The Starcoin contract account does not have the signature authority , and same as the Ethereum contract account, the transaction cannot be initiated proactively.

How does Starcoin implement contract accounts

Starcoin's account's code in Stdlib's Account.move, it implements Externally Owned Account and Contract Account . The Move code related to the contract account is very concise and ingenious, making full use of the advantages and features of Move. The following are the main implementations of Starcoin contract accounts:

// SignerDelegated can only be stored under address, not in other structs.
struct SignerDelegated has key {}
// SignerCapability can only be stored in other structs, not under address.
// So that the capability is always controlled by contracts, not by some EOA.
struct SignerCapability has store { addr: address }

public fun is_signer_delegated(addr: address): bool {
    exists<SignerDelegated>(addr)
}

native fun create_signer(addr: address): signer;

In the above code, there are two Structs:

• SignerDelegated: A marked resource stored in a contract account, which cannot be copied, discarded, modified, or transferred. If there is is_signer_delegated under an account, it means the contract account, otherwise it is an external account
• SignerCapability (Capability is a commonly used programming idea in the Move contract, usually expressing authority): It means the signature authority of the contract account addr. Whoever controls the SignerCapability of the addr can control the addr account. SignerCapability is also a resource that cannot be copied, discarded, modified, and can only be forwarded.

SignerDelegated is like a lock, and SignerCapability is like a key. The code also includes two functions:

is_signer_delegated: Call the is_signer_delegated function to make a judgment when verifying the transaction, and prohibit the contract account from actively initiating transactions (because the contract account does not have the authority to sign, it cannot actively initiate transactions) create_signer: create_signer is native. The account with SignerCapability of addr can call the create_signer function, switch to the addr contract account through the code, and run any contract code as the addr contract account. The above is the main implementation of the Starcoin contract account. Starcoin host SignerCapability(the signature authority of the addr contract account), and implement the ability to "switch accounts" in the contract code. What are the benefits of doing this? We will discuss it later when we discuss the application scenarios of contract accounts.

Create Starcoin's contract account

As we said earlier, the implementation of Starcoin accounts is unified, and contract accounts and external accounts can be converted to each other. Unlike Ethereum's contract account creation process, Starcoin's contract account creation process is just an additional step of "host signature authority" on the basis of the external account creation process. The following figure shows the process of creating an account in Starcoin.

Application scenarios of contract account

Starcoin host SignerCapability(the signature authority of the addr contract account),to implement the ability to "switch accounts" in the contract code. What are the benefits of doing this?

• Any contract that has the authority to sign SignerCapability can switch to the identity of the addr contract account, and write data to the Data part of the addr contract account
• Any contract that has the authority to sign SignerCapability can switch to the identity of the addr contract account, and call any contract function that requires Signer parameters

The above are the important capabilities of the Starcoin's contract account.

1. Examples of using contract
2. Let us imagine such a scenario. Suppose there are general users and VIP users on a certain platform, and different pool data is read and written for different types of users. At the stage of contract design, considering the security of Common Pool and VIP Pool, the ability to directly initiate transactions is not provided, and the SignerCapability of the signature authority of the two Pool contracts is entrusted to Category Contract. When the user calls the contract, the user type is determined first, and then the identity is switched according to the type using the corresponding signature authority, and then corresponding contract is called. This can easily unify the user's entrance, ensure the correct business algorithm, and better provide the security of the contract.

1. Starcoin's first contract account: Genesis Account
2. Many examples of contract account applications can also be found in Starcoin's Stdlib, the most typical one is GenesisSignerCapability. GenesisAccount is Starcoin's first contract account. It has no private key and is not managed by anyone. It is an extremely special account. At the same time, GenesisAccount is responsible for storing some global data. It is the registration center of NFT and Oracle. How to implement it? Let's take a look at the core code of the GenesisSignerCapability contract:

       struct GenesisSignerCapability has key {
           cap: Account::SignerCapability,
       }
   
       public(friend) fun get_genesis_signer(): signer acquires GenesisSignerCapability {
           let cap = borrow_global<GenesisSignerCapability>(CoreAddresses::GENESIS_ADDRESS());
           Account::create_signer_with_cap(&cap.cap)
       }

From the above code, we can see:

• GenesisAccount has no private key and is not managed by anyone. The signature authority SignerCapability is entrusted into the contract
• GenesisSignerCapability keeps the signature authority of GenesisAccount: SignerCapability, and stores it as global data under the account of GenesisAccount
• get_genesis_signer function is the visibility of friend. Through function authorization access, NFT and Oracle contracts can "borrow" the signature authority SignerCapability of GenesisAccount, thereby implement the function of the registration center, so that anyone can register for NFT and Oracle

On the premise of ensuring the safety of GenesisAccount, entrust signature authority SignerCapability into the contract, and the NFT and Oracle of Stdlib have been well applied, storing very important global data.

Conclusion

Compared with Ethereum's account model, Starcoin's account model has many advantages. It can cover all scenarios of Ethereum, and at the same time, it can solve many problems faced by Ethereum. It can be said that Starcoin has a more advanced account model.

Starcoin cleverly implements external accounts and contract accounts on a unified account model. External accounts are the entry point for general users. The contract account allows the contract to easily have the ability to "switch identities", which expands more interesting scenarios for the contract.

Originally published at https://starcoin.org.