if type_groups.get(hash(input.type)):
(script.code_hash == secp256k1_blake160_sighash_all && script.hash_type == “type” && script.args.size == 20) ||
假设有一个生意业务：
向网络广播
8、since
}
CKB 将执行所有按照返回值验证的 script group。此处遵循类 unix 系统中历程退出状态的约定：返回值为 0 代表验证通过，而其他返回值代表验证异常。
(script.code_hash == secp256k1_blake160_multisig_all && script.hash_type == “type” && （script.args.size == 20 || (script.args.size == 28 && script.args[20..28].is_valid_since_format))
class ScriptGroup:
pub fn serialized_size(&self) -> usize { // the offset in TransactionVec header is u32
tx_hash: Byte32,
transaction.outputs.all{ |output|
此验证旨在防备名目不正确的生意业务，譬喻在 Common Gotchas 中提到的生意业务。
let script = output.script
}
对付每个 input 和 dep，假如引用的 output 生意业务是 cellbase，那么它必需至少颠末 4 个 epoch 确认。
input: [cell_1 {lock: A, type: B}, cell _2 {lock: A, type: B}, cell_3 {lock: C, type: None}]
默认的验证逻辑包罗查抄各类对象：
3、inputs 不是空的
当每个单独的生意业务举办验证时，剧本将首先被分成 group，然后以 script group 的单元顺序执行。每个 group 都是将具有沟通剧本 hash 的生意业务分组在一起而建设的。请留意，output 的 lock script 将不会在生意业务验证期间执行。
def split_group(tx):
lock_groups: Dict[Hash, ScriptGroup] = dict()
https://github.com/nervosnetwork/ckb-system-scripts/blob/865f4d7697cc979d62111e49f2fb12a3607a4eb9/c/ckb_syscalls.h group(A, input:[0, 1], output:[]),
type_groups[hash(input.type)] = script_group
步调 1——Resolve
type_groups[hash(input.type)] = script_group
else:
https://github.com/nervosnetwork/ckb/blob/44b0d3595c31a29aef81e74360ba8613cd0dd27f/script/src/type_id.rs
script_group.input_indices.append(index)
group(C, input:[2], output:[]),
return error()
5、capacity
output: [cell_4 {lock: D, type: B}, cell_5 {lock: C, type: B}, cell_6 {lock: G, type: None}, cell_7(lock: A, type: F)]
6、duplicate_deps
除了一种范例的合约，即 TypeId 合约之外，大大都合约都是如上所述举办验证的。TypeId 合约利用非凡的法则，直接在剧本代码中编写，而且不启动 VM。有关更多信息，请拜见代码:
验证步调需要查抄如下要素：
特定法则
lock_groups[hash(input.lock)] = script_group
生意业务提交到当地节点后，节点还会输出生意业务 id，您可以利用该 id 跟踪生意业务的状态。
步调 2——验证
self.output_indices = []
在 CKB 中，每个生意业务都是单独执行的，即每个生意业务都有本身独立的 VM 情况。固然执行了多生意业务并行验证，可是 VM 内部没有多线程情况。
if input.type:
· 状态存储：Cell Model
1、版本（今朝必需是 0）
BlockAssembler 将从 pending 池和 proposed 池中为块模板获取 proposal 和生意业务，具体可参考：Two-Step Transaction Confirmation：
执行单位
deps 不能反复
type_groups: Dict[Hash, ScriptGroup] = dict()
请留意：在执行 script 时，script 不知道它是 type script 照旧 lock script。script 需要通过查抄 args 或 witness data 来本身办理这个问题。
当执行每个 script group 时，将记录 script 的执行本钱，并将所有资源耗损的总和与答允的 max_block_cycles 上限举办较量。
since 值必需遵循 RFC：Transaction valid since
// molecule::NUMBER_SIZE = size_of::<u32>() 4
Syscall
它将按这样的方法分组：
https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0020-ckb-consensus-protocol/0020-ckb-consensus-protocol.md#two-step-transaction-confirmation
else:
CKB 生意业务验证生命周期
2、serialized_size 必需小于如下限制：我们都知道 Nervos CKB 是一个以状态为中心的架构，而且用生意业务暗示状态变动和迁移。并且 Nervos CKB 提供基于 Cell Model 和 CKB VM 的编程模子。在这个模子中，去中心化的应用逻辑被分成两个部门：状态生成和状态验证。
if type_groups.get(hash(input.type)):
def __init__(self, script):
}
https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0017-tx-valid-since/0017-tx-valid-since.md
之前 CKB 开拓者 luochao 给各人先容了如何用最常见最简朴的要领在 CKB 上构建生意业务——也就是状态生成。在本篇文章中，CKB 开拓者 DingWei Zhang 和 luochao 将继承别离为各人讲授状态验证的开拓细节：「CKB 生意业务验证的生命周期」和「CKB VM 验证法则」。 https://github.com/nervosnetwork/ckb/wiki/Common-Gotchas#nervos-dao
}
CKB VM 将执行生意业务剧本，并输出所耗损的 cycles 个数。
type_groups.get(hash(input.type)).input_indices.append(index)
}
return list(lock_groups.values()) + list(type_groups.values())
本质上，生意业务 input 只是指针，如下所示：
for index, input in enumerate(tx.inputs):
「output data」字段的数量必需便是 outputs 的数量
group(F, input:[], output:[3])
在编写措施时，确定操尽兴况和运行时行为很是重要，以便措施的执行布局尽大概靠近措施建设者的期望。譬喻：在编写 Python 措施时，需相识 Python 中 GIL 的影响、硬件指令的预期执行时间、流水线筹划等。
首先，发送方会结构一笔生意业务，通过 RPC 提交。生意业务由提交到的 outputs_validator （从 0.27.0 版本引入）举办验证。
4、inputs 是成熟的
script.is_null || script.code_hash == dao && script.hash_type == “type”
7、outputs_data_verifier
假如验证乐成，当前节点将生意业务（带有 cycles 值）广播给它的所有对等节点（它所毗连的节点）。
for group in split_group(tx):
]
无论执行哪个 script group，script 都可以在执行期间会见整个生意业务数据。这种设计的一个利益是 script 记录属于当前 script 的cell 的索引。这相当于删除生意业务数据并验证沟通的 lock script 或 type script，但只需执行一次即可完成多个 cell 的验证。淘汰了验证资源的耗损，，并为生意业务的 data set 提供了公有情况。
https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0009-vm-syscalls/0009-vm-syscalls.md
def run():
[
代码如下：
inputs().is_empty() || outputs().is_empty()
lock_groups.get(hash(input.lock)).input_indices.append(index)
状态生成逻辑在客户端运行，新的状态被打包成生意业务，验证通事后广播到整个网络。简朴来说 CKB 的编程模子分成如下三部门：
else:
· 状态验证：CKB VM
if output.type:
self.as_slice().len() + molecule::NUMBER_SIZE
index: Uint32,
script_group.input_indices.append(index)
|| (script.has_lock_period() && since.is_absolute())
情况
VM 的 syscall 可以通过 group(input/output index) 加载这些对应的 cell，以完成一次性验证。
Transaction {
input capacity 的和必需小于或便是 output capacity
CKB VM 验证法则
if lock_groups.get(hash(input.lock)):
Tx-pool验证
我们都知道 CKB VM 是基于 RISC-V 指令集开拓的虚拟情况。下面，我们将先容在 CKB 验证期间 VM 的情况，包罗提供的一些系统挪用等相关配景常识。
在验证失败的环境下，将不再广播生意业务。生意业务流经各个「完整节点」，这些节点反复前面步调中描写的验证进程，并查抄 cycle 值是否与验证生意业务时利用的实际 cycle 相匹配。
type_groups.get(hash(input.type)).output_indices.append(index)
self.script = script
另外，可以将其设置为 passthrough 以跳过此验证。
script_group = ScriptGroup(input.type)
struct OutPoint {
self.input_indices = []
CKB 利用 two-step 举办生意业务确认。生意业务将在 tx-pool 中分别为差异的状态（pending 状态和 proposed 状态）。当一个块上链时，生意业务的状态将改变。当最新的块变动时，将从头扫描 tx-pool 中的所有生意业务，以确保它们仍然有效。
我们在生意业务执行之前通过指针收集引用的数据，这个进程称为「理会生意业务」。我们还需要查抄这个生意业务的所有输入都是有效的（没有反复或双花）。
RPC
for index, output in enumerate(tx.outputs):
关于 Syscall 的内容，请参考：RFC：VM Syscalls 和相关代码：
if vm_run(group) != 0:
· 状态生成：链下
group(B, input:[0, 1], output:[0, 1]),
script_group = ScriptGroup(input.type)
let script = output.type
在广播生意业务并进入 mempool 之前，生意业务将在当地验证和执行。
script_group = ScirptGroup(input.lock)
script_group.output_indices.append(index)
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
