执行模式
本页介绍 Kaia 智能合约的执行模型、数据结构和生命周期。
执行模式
平台 API 可生成交易,详见 Platform API Specification。 这些交易被发送到_共识节点(CNs\ )_,存储在一个区块中。 CN 检查收到的每笔交易是否有效。 有效的事务会保存在事务池中,否则会被丢弃。 CN 在其事务池中选择当前区块中的可执行事务,并逐一执行。
要执行交易,发送方必须支付一定数额的 KAIA 作为交易费。 KAIA 的这笔交易费是根据天然气和乘数(即_)、单价计算的。 气体是计算的基本单位。 在 Kaia 节点上执行的每个操作都会消耗预定量的气体。 交易所需的 KAIA 确切金额按交易费中的公式计算。 如果发送方提交的交易附带的气体不足,交易可能会失败。 如果发件人账户余额不足,交易也可能失败。
当一个事务成功执行后,它就会被包含在当前区块中。 CN 收集交易,直到达到区块气体限制或区块时间限制。 然后,CN 将这些交易生成一个区块。 这一步需要在区块中填写几个字段。 例如,它必须计算交易、收据、状态等的哈希值。 填写完所有必填字段后,CN 会生成一个区块哈希值。
区块生成完成后,区块会传播到所有其他 CN。 其他 CN 都会验证传播的区块,并通过 BFT 共识算法就验证结果达成共识。 当大多数 CN 成功完成验证过程后,区块就会被存储到区块链中。 由于 BFT 共识算法满足即时终局性属性,因此区块是终局的,永远不会被删除。 一个区块最终 完成后,该区块中所有事务的执行都将得到不可逆转的保证,而且如果发送者提出要求,其执行结果可以返回给发送者。
增强整体提案人和委员会遴选的随机性
Kaia 采用了一种新机制,在区块提议者和委员会选择过程中引入了可验证的链上随机性。 这种机制涉及到块标头中的两个新字段:randomReveal "和 "mixHash"。
在这个系统中,区块提议者生成并承诺随机值。 区块中的 "randomReveal "字段包含提议者的签名,该签名使用特定签名方案生成,并根据当前提议的区块编号进行计算。 然后,"mixHash "就会使用这个揭示的随机值和其他区块数据进行计算,从而为网络创建一个随机源。
区块提案人和委员会的遴选过程就是利用这种生成的随机性。 使用这种随机性的目的是使选择过程更加不可预测和公平,从而提高网络的整体安全性。 这种机制的一个特殊用例是允许区块提议者在上一个区块完成之前保持隐私,从而为网络增加了一层额外的安全性。
执行流程形成了一个循环,每个区块的随机性都会影响未来区块提议者和委员会的选择。 这就为这些过程引入了不可预测性因素,同时又保持了其可验证性。
值得注意的是,虽然这种随机性被用于选择过程,但在区块挖掘结束时,奖励仍会根据投注金额直接修改状态进行分配。 随机性决定了哪些验证者被选中成为接受奖励的委员会成员,而不是分配奖励的数量。
若干安全考虑因素对这一机制至关重要:
- 为防止重放攻击,每个区块的每个
randomReveal
值都必须是唯一的。 - 区块提议者必须诚实地生成并提交其 "随机揭示",以防止 "混合哈希 "被篡改。
- 提案者必须在区块提案之前对其
randomReveal
保密,以防止其他参与者预测和可能的操纵。 - randomReveal "必须经过适当签名和验证,以防篡改。
这种机制的目的是在区块创建和委员会选择过程中引入不可预测性,同时保持可验证性。 值得注意的是,虽然本系统提供了一个增强随机性的框架,但随着网络的发展和完善,使用这种随机性的提案人和委员会选择算法的具体实现方式可能会随时间推移而发生变化。
交易执行限制
Kaia Mainnet 和 Kairos Testnet 目前对交易执行有以下限制:
- 您可以设置交易的 gasPrice,但这意味着这是您能支付的最高价格。 实际天然气价格将由网络决定。 更多详细信息,请参阅天然气价格概览
- A block proposer shall not spend more than 250 ms in block execution. 请参阅 计算成本
- 交易支出不能超过计算成本限额。 请参阅 计算成本
智能合约部署限制
Kaia 对智能合约的部署实施了多项限制:
- 根据 EIP-3541,从 Kore 硬分叉开始,不允许部署以 0xEF 字节开始的新合约代码。
- 自上海硬分叉以来:
- 如果初始代码长度超过 49 152 字节,新合同代码的部署将被拒绝。
- 新合同代码的长度不能超过 24 576 字节。
- 这些限制基于 EIP-3860。
- 已启用智能合约账户 (SCA) 覆盖外部所有账户 (EOA)。
数据结构
账户
Kaia 区块链平台中的账户是一种数据结构,包含个人余额或智能合约的相关信息。 Kaia 重新设计了账户模型,以提供更好的 DX 和 UX。 有关账户模型的详细信息,请参阅 此处。
交易
区块链平台中的交易是节点之间发送的改变区块链状态的信息。 Kaia 还重新设计了交易模式。 根据交易的目的将其分为不同类型,以寻找优化性能的机会,并支持重新设计的账户模式。 有关交易模式的详细信息,请访问 此处。
国家
Kaia 的状态是账户状态的集合。 如果 Kaia 节点以相同的顺序处理了相同的区块,则各节点的状态必须相同。 在 Kaia 节点上执行事务时,状态会发生变化。
下表列出了存储在该州的账户数据。
组件 | 说明 |
---|---|
nonce | 整数值,表示该账户执行的交易次数。 提交交易时,交易的 nonce 应等于账户的 nonce。 |
balance | 一个整数值,表示该账户目前拥有的 KAIA 数量。 |
storageRoot | 包含账户中所有存储变量值的 Merkle Patricia Trie 根的 256 位散列。 |
codeHash | 账户字节码的哈希值。 这个值是不可变的,这意味着它只有在智能合约创建时才会被设置。 如果账户是 EOA 或 EA,该值将设为空值。 |
街区
区块是 Kaia 区块链的重要元素,因为区块链实际上是由区块链组成的。 下表列出了程序块中的组件。
组件 | 说明 |
---|---|
baseFeePerGas | 每个气体的基本费用。 只有当该块编号的 EthTxTypeCompatibleBlock 被激活 时,才会返回该值。 |
blockScore | Former difficulty. 在 BFT 共识引擎中始终为 1 |
extraData | 该数据块的 "额外数据 "字段。 |
gasUsed | 该区块内所有交易使用的气体总量。 |
governanceData | RLP 编码的治理配置 |
logsBloom | 区块日志的 Bloom 过滤器。 待处理块时为 "空"。 |
number | 区块编号。 待处理块时为 "空"。 |
parentHash | 块的父块的哈希值。 |
proposer | 区块提议者的地址。 |
receiptsRoot | 区块收据三元组的根。 |
reward | 接收区块奖励的地址。 |
size | 整数,该数据块的大小(字节)。 |
stateRoot | 区块最终状态三元组的根。 |
totalBlockScore | 该区块之前链上总 blockScore 的整数。 |
transactionsRoot | 区块的交易三角根。 |
timestamp | 区块整理时间的 Unix 时间戳。 |
timestampFoS | 区块整理时间戳的秒分数。 |
transactions | 事务对象数组,或 32 字节事务哈希值(取决于最后给定的参数)。 |
voteData | RLP 编码的提案人治理投票 |
智能合约生命周期
智能合约由代码和数据的集合组成,这些代码和数据位于 Kaia 区块链上的特定地址。 合约账户能够相互传递信息,并进行实际上完整的图灵计算。 合约以 Kaia 特有的二进制格式存在于区块链上。 目前,Kaia 支持一种二进制格式--以太坊虚拟机字节码(Ethereum Virtual Machine (EVM));不过,未来还将支持其他格式。
创建智能合约
通过向空地址发送以二进制为数据的交易,可以在 Kaia 区块链中创建智能合约。 二进制文件可以是多种格式,但 Kaia 目前支持一种二进制文件格式,即 EVM 字节码。 值得注意的是,这项交易的执行需要付款。 交易存储到区块后,发送方账户余额将根据交易费用模式进行扣减。 一段时间后,交易应出现在一个区块中,该区块会确认交易涉及的状态已达成共识。 此时,智能合约已存在于 Kaia 区块链中。