Due to the limitations of the machine configuration, the docker deployment is not complete and starts directly.
=========================================================================
foreword
In my opinion, understanding the account permissions system in EOSIO is crucial for developing on it. These include: accounts, key-pairs, wallets, authorities & permissions, and the relationship between them. There are very detailed explanations on the official wiki and in the white paper. I also researched, thought, and asked for advice and practice for a long time before I understood. Here are some of my own explanations. If there are any inaccuracies, please point out in time (lupeihe@gmail. com).
Accounts
Unlike ETH and BTC, EOS weakens the status of private keys, and the on-chain interaction is based on accounts (similar to BTS and GXB). Compared with a long list of hash values, accounts are more readable and easier to popularize. It is a unique identifier on the chain, stored on the chain, and interacts directly with the chain. By configuring different permissions for an account, it can be granted and limited to the actions (actions) it can perform.
Key-pairs
Wallet
Authorities and permissions
Once an account is created, it is granted two default permissions: owner and active. owner: Having this permission means that he is the owner of this account (there can be multiple accounts with owner permission), owner is the highest permission of this account, and can do any operation on this account (equivalent to admin or root permission), but generally It will not be used for operations, and some special operations, such as restoring permissions, etc., are generally stored in cold storage. active: Generally used for transfer, voting for block producers (super nodes) and modification of some permissions. (specifically need to refer to the api)
In addition to these two basic permissions, you can also customize specific permissions. The official example is the publish permission. For example, to publish an article on a certain dapp requires the publish permission. Both @bob and @stacy only need one of their own signatures to publish the article, and the last public key account requires another signature in addition to its own signature. The account's signature can only be published because its own signature weight is only 1 under publish.
note: Both the account name and the public key can represent a certain weight to set permissions (signatures).
Weight refers to the weight that this account can grant to a certain permission, and Threshold is the weight threshold that needs to be met to have this permission.
| Permission | Account | Weight | Threshold |
|---|---|---|---|
| owner | 2 | ||
| @bob | 1 | ||
| @stacy | 1 | ||
| active | 1 | ||
| @bob | 1 | ||
| @stacy | 1 | ||
| publish | 2 | ||
| @bob | 2 | ||
| @stacy | 2 | ||
| EOS7Hnv4iBWo1pcEpP8JyFYCJLRUzYcXSqt... | 1 |
interrelationship
I drew the approximate relationship between them myself, which may not be rigorous.
I think the biggest advantage of the EOSIO permission control system is its high flexibility, which is more suitable for complex social application scenarios. Because of this, a deeper understanding needs to be used in specific scenarios to have a deeper experience.
After building the local EOSIO source code, start the single-node test network ($nodeos). Use the cleos client command to perform related tests and verifications. I will not go into details. Just refer to the github documentation directly. It is nothing more than the use of some command parameters or api. The understanding of the entire permission control system is the core of developing smart contracts and Dapps in the future.
Next time prepare to start the exploration of smart contract development~~
ps: Pulled the latest code, and the minimum memory of the build has been increased to 7g.