知识库更新-Atom模型

Introduction

Tempo (the Radix consensus algorithm) provides one fundamental constraint: eventual consistency of state. To meaningfully build on top of this constraint, we need high-level, application-oriented constraints and structures. The Atom Model was designed to empower decentralised applications by enabling extensible implementations of financial systems (creating, minting, transferring and burning of tokens), data storage and transfer (messaging) and more.

Specification

在分布式数据存储中，所有参与者都必须就一组控制状态如何更改的规则达成一致。 由于并非每个节点都可以存储所有状态，因此必须将一个状态分成多个较小的状态，这些状态可以在不需要所有其他状态的情况下进行验证。 为此，状态更改必须是明确的，并且需要支持一种接受或拒绝一批状态更改为一个单元的机制。 在Radix中，这些状态变化是粒子，而粒子的原子批处理是原子。 Atom模型描述了其结构，规则和与Tempo的接口。

Hierarchy overview

分类帐的状态是微小状态变化的总和。 分类帐的这些各个状态更改称为“粒子”。 要将粒子（即状态更改）提交到分类帐，必须将它们放置在Atom中。

更高版本的Atom中的粒子可能会更新作为更早版本的Atom的一部分存储的粒子（例如，存储某些令牌已用完）。 因此，分类账的当前状态由所有最新的粒子（即状态更改）组成，它们的相对顺序由Tempo确保。

当要立即提交许多这样的状态更改时，很难辨别哪些内容属于同一类。 这对于验证（即接受/拒绝更改）以及最终用户（“哪个粒子代表什么？”）来说都是麻烦的。 为了提供清晰的粒子关系机制，相关粒子被分组为粒子组。

请注意，任何粒子都必须作为粒子组的一部分提交，粒子不能直接进入Atom。 这种显式的分组机制使开发库，钱包以及当然Radix节点的实现变得更简单，因为本地支持管理粒子之间的关系。

原子，粒子群和粒子是原子模型的核心结构元素。 以下各节详细定义了它们。

Particles

Particles are the core component that power the Atom Model, as they can be mixed and matched with other Particles in an Atom to form arbitrarily complex actions. There are many different types of Particles for different purposes which are explained here. Therefore, when talking about Particles it is important to differentiate between Particle types, which describe a type of Particle, and Particle instances, which describe instances of a certain Particle type. Particle instances form the state of the ledger, while particle types define the particle instance's state guarantees and rules.

Particle instances of different Particle types can be mixed within an Atom and within a Particle Group as permitted by the Particle type. What a Particle type can permit and disallow about the state of its instances is further explained in the article Particle Types.

Particles are Finite State Machines

建立后，可以在以后的Atom中更新粒子实例。 更新是指将粒子的生命周期状态更改为另一状态-例如 从“不存在”变为“有效”，或者从“有效”变为“无效”，甚至从“有效”变为“有效”。 无效-将粒子实例标记为无效-对于可以以某种方式使用的所有粒子类型（例如令牌）很有用。

更新粒子不会更改其内容，但会更改其状态。 实际上，相等的粒子的内容用于标识具有相同内容的后续粒子意味着要进行更新。 “不存在”，“有效”和“无效”是任何粒子实例的三个可能的生命周期状态，并且粒子类型指示可以按哪个顺序允许哪些状态。 也就是说，粒子实例可以假定的有限数量的生命周期状态由粒子类型描述的生命周期有限状态机控制。 考虑到粒子生命周期状态，请考虑一个如何随时间更新粒子的示例：

注意，每个箭头标记从一个生命周期状态（在此示例中为绿色，即“有效”）到另一生命周期状态（在此示例中为红色，即“无效”）的过渡。 为了清楚起见，已省略了从不存在到有效存在的过渡，因为它们是隐式的。

Particle Groups

粒子组是一组在Atom中具有元数据的相关粒子的分组，代表一个应用程序级操作。 动作可能是发出涉及多个粒子的转移，支付费用，发送消息，或者是用户或开发人员希望分组的任何逻辑动作。

Metadata

与Atom相似，粒子组包含基于字符串的元数据键值存储。 此元数据未经任何方式验证或约束（除Atom的大小限制外），可以免费使用。 请注意，由于所有粒子组都包含元数据，并且它不会以任何方式影响Atom模型的其他方面，除非将在本文的其余部分进行明确讨论，否则它将被省略。

Particle and Particle Group Indices

为了唯一地标识Atom中的粒子组，将按照它们添加到Atom的顺序对其进行索引。 为了唯一地标识粒子组中的粒子，将按照将粒子添加到粒子组的顺序对粒子进行索引。 请注意，两个索引都是从零开始的。

Using the index of the Particle Group a Particle resides in, and the Particle's index within that group, a Particle can be easily referenced within an Atom following the JSON pointer standard as follows:

< atomId >/groups/< groupIndex >/particles/< particleIndex >

Note that 'atomId' is computed using the hash of the Atom. See Formal Definition for further explanation. For example, the Particle identifier

123 /组/ 1 /粒子/ 2

引用具有索引1的粒子组中具有索引2的粒子，如下所示：

这在调试原子被节点拒绝时非常有用，因为它可以以人类可读的方式指向特定的粒子。

Dependencies within an Atom

通常需要提交原子状态更改，该状态更改由相互依赖的多个更改组成。 原子中的粒子组可以取决于它之前的粒子组的输出，并按索引排序。

Atoms

原子是分类账上状态更改的原子容器。 当Atom提交到网络时，要么接受并存储其所有粒子（即状态更改），要么不接受。

除了粒子形式的状态变化（分为粒子组）外，原子还包含元数据，签名和时间证明。 签名对于确保Atom中提交的状态更改的合法性至关重要，而时间证明对于在账本的通用状态上达成共识至关重要。 请注意，临时证明不是由客户端而是由节点附加。 由于签名和时间证明与Atom模型没有直接关系，因此本文其余部分将省略它们。

Metadata

Atoms also contain a string-based key-value store of metadata. This metadata is not validated or otherwise constrained in any way (besides size restrictions of an Atom, see Formal Definition) and can be freely used. Note that since all Atoms contain metadata and it does not influence other aspects of the Atom Model in any way, metadata will be omitted for the rest of this document.

Atomicity

Atom的原子性对于构造复杂的动作很有用，在该动作中，所有状态更改都被接受或拒绝了一个内聚单元。

仅当没有任何粒子被拒绝时才接受原子，无论它们在原子中的位置如何。

Formal Definition

Formal Structure

Atom模型的正式结构定义是一个高级概述。 出于此定义的目的，[item] +表示必须至少包含一次项目，[item] *表示可以任意多次包含该项目，而item则应表示该项目必须恰好包含一次。

General Metadata

常规元数据是有关基于字符串的键值存储中某个项目（例如Atom或粒子组）的任意数据。 字符串是UTF-8，它们的键和值是任意的。 唯一的限制是大小，这是整个Atom大小限制间接施加的。 常规元数据定义为

键= Value = Metadata = [Key=Value]*

Particle

The structure of Particles is defined in the Particle document. As Particles do not share any required structure, there is no common base structure.

Particle Group

粒子组包含带有常规元数据的粒子的非空索引列表。 粒子组的结构是

正式粒子群结构

粒子组= General Metadata [Particle]+

Atom

Atom包含带有Atom元数据的粒子组的非空索引列表。 Atom元数据与常规元数据类似，不同之处在于它具有必须存在的特殊值并具有值约束：

所需的元数据键目的价值约束时间戳记提交原子的时间戳正整数必须在创建宇宙之后

Atom的结构定义为

原子= Atom Metadata [Particle Group]+

Atom Size Restrictions

紧凑的序列化Atom可能具有的最大字节数是65536。

Formal Schema

正式模式是对象的JSON序列化版本必须遵循的JSON模式。

Particle

粒子的模式在粒子文档中定义。 由于粒子不共享任何所需的结构，因此没有通用的基本架构。

Particle Group

粒子组的正式JSON模式可在此处获得。

Atom

此处提供了Atom的正式JSON模式。

Implementation

Atom模型目前在Java上的Radix Core（Radix节点的主要实现）和Radix Client库的开发分支上实现。

Radix Core (Java)

目前，只有Radix Core开发人员才能访问Radix Core实施。

Client libraries

Language	Status	Library
Java	Available	radixdlt-java
JavaScript	Available	radixdlt-js
Kotlin	Available	radixdlt-kotlin
Swift	In development	radixdlt-swift

Join The Radix Community

Ťelegram for general chat
​Discord for developers chat
​Reddit for general discussion
Forum for technical discussion
​Ťwitter for announcements
​Email newsletter for weekly updates
Mail to hello@radixdlt.com for general enquiries

from: https://dev.to//radixdlt/knowledgebase-update-atom-model-263i