EOS-contract
tyleraccount
Description EOS Token Sale Claim Key
Public key EOS5p6VPhWXp6UBojRsYbimjuwWsBLth6aFTsMrnuFoX2f2oM4LGZ
Private key 5HubX63BtvNRnRKUuXNLNR9FD34FxnudQuGdmev8kA3c26NCW4y
common usage
cleos -u http://192.168.1.85:8888 get table astyler12312 astyler12312 |
compile contract
1.2.x 旧版本方式
#使用 -o 生成wast文件和wasm文件 |
1.3.x 新版本方式
eosio-cpp -abigen ./xx.cpp |
deploy contract
cleos -u https://api-kylin.eoslaomao.com set contract astyler12312 ./buyname |
invoke action
push action |
查询套餐
cleos -u http://192.168.1.85:8888 get table vip vip prices |
common concept
eosiocpp是一个c++生成wasm和ABI文件的工具。 |
common concept
An EOSIO Smart Contract consists of a set of action and type definitions.
Action definitions specify and implement the behaviors of the contract.
The type definitions specify the required content and structures.
EOSIO actions operate primarily in a message-based communication architecture. A client invokes actions by sending (pushing) messages to nodeos.
EOSIO Smart Contracts can communicate with each other, e.g., to have another contract perform some operation pertinent to the completion of the current transaction, or to trigger a future transaction outside of the scope of the current transaction.
EOSIO supports two basic communication models, inline and deferred.
Communication among contracts should be considered as occurring asynchronously. The asynchronous communication model can result in spam, which the resource limiting algorithm will resolve.
There is no guarantee that a deferred action will be executed.
Action Name Restrictions
Action types are actually base32 encoded 64-bit integers.This means they are limited to the characters a-z, 1-5, and ‘.’ for the first 12 characters. If there is a 13th character then it is restricted to the first 16 characters (‘.’ and a-p).
Transaction Confirmations
By means of confirmation, you should see the transaction in the transaction history with the block number of which it is included.
From a global view of an EOSIO blockchain, every node in the EOSIO network gets a copy of and runs every action in every contract.
Some of the nodes are doing the actual work of the contract, while others are processing in order to prove the validity of the transaction blocks.
receiver is the account that is currently processing the action.
code is the account that authorized the contract.
action is the ID of the currently running action.
Transaction Limitations
Every transaction must execute in 30ms or less. If a transaction contains several actions, and the sum of these actions is greater than 30ms, the entire transaction will fail. In situations without concurrency requirements for their actions this can be circumvented by including the CPU consuming actions in separate transactions.
合约通信
EOSIO中的合约可以相互通信。它是通过基于消息的通信架构实现的。
EOS通信模型就是他们沟通的方式。通信模型有两种类型:Inline Communication Model(内联通信模型)和Deferred Communication Model(延时通信模型)。
内联操作(内联通信模型)
用户从智能合约A执行操作(Action #1)。当操作开始执行时,它会触发另外两个操作:来自智能合约B的操作Action #1.1和来自智能合约C的操作Action #1.2。一切都在当前交易中完成。
在当前交易中执行并与其完成相关的操作,称为inline action即内联操作。
重要的是要记住内联操作是作为调用操作的一部分执行的。因此,它们与原始交易的范围和权限相同。这是他们将被执行的保证。如果其中一个操作失败,则整个交易将失败。
延时操作(延时通信模式)
根据生产者的判断,延时的操作最好可以安排在稍后的时间运行。无法保证延期操作将执行。
即使它们不属于同一交易,它们也具有发送它们的合约的权限。
交易可以包含N个操作。但是,每个交易必须在30ms或更短的时间内执行。如果交易包含多个操作,并且这些操作的总和大于30毫秒,则整个交易将失败。