Чтобы сделать новую модель немного более понятной, давайте сравним ее с двумя наиболее распространенными на сегодняшний день моделями хранения данных, которыми являются UTXO (биткойн) и модель учетной записи (Ethereum). Поскольку модель записи представляет собой своего рода гибрид этих двух, это может помочь освежить информацию об обеих, прежде чем углубляться в нее.

Биткойн (UTXO)

Модель UTXO была оригинальной парадигмой хранения, в которой выражалось владение Биткойнами. Как это работает с точки зрения очень высокого уровня, так это то, что количество BTC по сути похоже на связки магнитов. Когда вы получаете определенное количество BTC, оно приходит к вам как единый объект; допустим, вы получаете от кого-то 2 BTC. Эти 2 BTC хранятся в вашем кошельке в виде единого блока из 2 BTC, и если вы хотите отправить кому-либо любую сумму денег, вы бы использовали этот блок 2 BTC в качестве входных данных для своей транзакции.

В транзакции этот блок затем "разделяется’ на все его выходные данные. Допустим, вы отправляете 0,5 BTC другу — затем этот блок в 2 BTC разбивается на блок в 0,5 BTC и 1,5 BTC (за вычетом небольшой суммы сборов, конечно). Затем блок 0.5 BTC отправляется вашему другу, а блок 1.5 BTC отправляется вам. Теперь каждый из ваших кошельков содержит один блок BTC, но в разных количествах. Естественно, по мере того, как вы начинаете получать больше транзакций, вы создаете несколько блоков внутри своего кошелька. Допустим, вы получили транзакции на 1,2, 0,6 и 0,8 BTC, и вы пытаетесь совершить транзакцию на 2,6 BTC (всю сумму). Затем транзакция примет эти 3 блока в качестве входных данных и соединит их (как магниты!), Чтобы создать результат для вашего получателя.

В этой модели владение монетами очень четко определено, а ресурс вполне осязаем. Участвуя в транзакциях, вы просто обмениваетесь кусочками того, что вы получили с течением времени. Легко сказать, откуда пришли деньги и как они перемещались с течением времени.

Ethereum (Account model)

The second great innovation in blockchain storage models is that the Account model does away with the fragmentation seen in the UTXO model. Instead, any type of specific account data is stored monolithically in a single storage structure. In the case of the blockchain native currency, this has the nice effect that any amount of money held always takes up the same amount of storage, as a single piece of information is just incremented or decremented over time, rather than having separate bits of data being moved around.

This account storage contains the amount of ETH held by the user, as well as a special number that increments for each transaction sent. This is used to avoid double-spending attacks (also known as a ‘nonce’). However, it can contain much more than that. Ethereum accounts can hold an arbitrary amount of bytecode and storage which are essential for smart contract functionality — this is how execution is facilitated on the Ethereum network, and how it innovated the world’s first on-chain execution model. An address can hold any amount of code that describes the functionality of a smart contract and contains a blob of storage associated with that smart contract. The important distinction to make is that all of the contract bytecode and data are kept in the same address. No matter how many people have interacted with it, all of the scores are kept on this smart contract address. All the data is central to this contract address, very much unlike the bitcoin storage model, where information is fragmented and put back together again as it moves through different accounts.

Алео (модель записи)

Затем появилась модель записи, цель которой - объединить лучшее из обоих миров. Впервые разработанный Aleo, он привносит что-то новое в таблицу, позволяя как программируемость Ethereum, так и использует фрагментацию состояния, наблюдаемую в Биткойне.

Для смарт—контрактов в Aleo байт-код контракта фактически хранится монолитно - что имеет смысл, потому что вы не можете фрагментировать фрагмент кода. Однако, чем она отличается от Ethereum, так это тем, что биты состояния, принадлежащие учетным записям, которые взаимодействовали с ней, фактически хранятся в самих учетных записях. Таким образом, пользователи имеют фактическое право собственности на свои данные для определенного смарт-контракта. Эти биты данных - это то, что мы называем "записями", и они могут содержать любой произвольный объем данных. Немного похоже на UTXOS, которые мы видим в биткойнах! Однако данные внутри этих записей могут быть изменены, увеличены, уменьшены и т.д. чтобы отразить изменения состояния, так же, как состояние изменяется в Ethereum.

Хороший способ думать об этом - это прекрасное сочетание программируемости Ethereum с концепцией осязаемых ресурсов UTXO в биткойнах. Кроме того, в Aleo эти записи могут быть зашифрованы и, таким образом, содержать личную информацию, с поддержкой работы с зашифрованными данными на уровне протокола, что упрощает пользователям и разработчикам работу с ними, рассуждения и выражения.

Another important distinction to make here is that the records do not actually get passed around like UTXOs are. This is why we consider it to be a hybrid model between UTXOs and the Account model. Account-specific state is stored in a fragmented manner, but mutated in place accordingly and never passed around.

Quite a lot, actually! This unique storage paradigm may seem a bit unintuitive at first — why would we fragment data like this when there’s already a perfectly viable model without it? Well, a nice property of this paradigm is that individual state is no longer correlated in the same way that it is in the Ethereum model, where instead all state is packed together and mutations need to happen step-by-step, as race conditions can occur otherwise.

What this gives way to, is that state can now be accessed concurrently, as long as it is clear that there are no conflicting read/write access attempts within blocks. Execution can thus be done in parallel since the state is not monolithic anymore, and provers can infer based on context which transactions are unconflicting. This does wonders for the throughput of the Aleo network. As the days of sequential, redundant execution are no more; we can now leverage (specialized) hardware to its full potential to alleviate throughput bottlenecks, both by delegating execution off-chain and performing it in parallel.

Наивно говоря, мы уже можем многого добиться в области масштабирования, просто используя модель записи для хранения в блокчейне Aleo. Пока не возникает конфликтов доступа к состоянию, выполнение может быть распараллелено. Кроме того, выполнение не нужно повторять, так как "проверяющие" будут запускать программы вне цепочки и просто загружать различия в состоянии и проверки достоверности в цепочке, что делает намного более экономичным запуск дорогих приложений dApps.

Но мы можем сделать еще один шаг вперед, и это начнет напоминать модель, которую Ethereum в настоящее время использует для масштабирования — свертки. Приложения могут выбирать последовательность транзакций своих пользователей и собирать их в течение определенного периода времени. После чего они могут быть объединены и объединены в одну транзакцию. Урегулирование будет происходить периодически, почти ничего не будет стоить (поскольку мутации объединены вместе) и приведет только к одному различию состояний и доказательству достоверности. Интересно, что Aleo позволяет создавать накопительные пакеты для конкретных приложений без необходимости запускать дополнительные цепочки блоков или заботиться о какой-либо лишней инфраструктуре, такой как мосты. По сути, он получает все преимущества от масштабирования без каких-либо неотъемлемых рисков, связанных с накоплением.

导言

基于区块链的系统包含在我们生活的许多领域，如DeFi或游戏等行业。 然而，许多现代区块链缺乏隐私性和可扩展性，这限制了用例的范围。 由aleo等零知识证明支持的零知识证明和块链承诺提供更好的可扩展性和隐私保证，以及启用新的区块链应用程序。 这包括新的DeFi应用程序，更复杂的web3游戏，甚至是基于人工智能的程序。 其中许多应用程序需要表示广泛的数字，包括小数。 Aleo自带Leo编程语言，大大简化了零知识程序的编程。 但是，它仅支持基于整数的数字。 在本文中，我们使用Leo分析了zksnarks中定点数的结构，这使我们也可以使用分数来计算广泛的应用。

定点数的简单实现

在实现定点数值表示法时，我们可以对变量使用Leo语言提供的整数类型。 此外，我们在内部指定了一个缩放因子，该因子定义了为值的小数点左侧的整数部分保留的数字，并且还定义了值的小数点右侧的小数部分。

假设我们想将值1.55表示为小数点后精度为两位数的定点数。 为此，我们可以输入变量i并为其赋值155，即1.55的值乘以100的缩放因子:

设i：u32=155;

现在我们可以用这个变量进行数学计算。 例如，要添加0.45，我们添加45（。45*100)到程序代码，这导致变量200的值。 在解释程序的输出数据时，我们需要将值除以100的缩放因子，以获得所需的十进制数系统-在十进制数系统中加法的结果为2。

同样，我们也可以进行乘法运算。 当用十进制表示法乘以2.50时，我们用定点表示法乘以250，然后将结果除以100的缩放因子。 例如，十进制中的2*2.5=5是指定点表示法中的200*250/100=500。 再次，当在定点数系统之外解释结果时，我们需要将定点数500除以100的缩放因子，以获得5的预期结果。

对于除法，我们的行为类似于乘法，但不是除法，而是乘以缩放因子。

例如，十进制中的4.5/0.5=9是指定点表示法中的100*450/50=900。 除以缩放因子，我们得到9的预期结果。

概括和要考虑的事情

如上例所示，缩放因子确定小数部分的位数。 我们对n个小数位使用了10^n的缩放因子。 通常，较高的缩放因子提供更高的精度，但是，我们必须记住此类型的可接受值范围。

在上述使用u32的例子中，一般范围是从0到232-1=4,294,967,295。 由于类型的二元性质，一般的概念是使用二的幂的比例系数S。 例如，当使用2〇=32的缩放因子时，对于小数部分使用5位，对于整数部分仅保留27位。 因此，整数部分的最大数是22⁷-1=134 217 727，小数部分的分辨率是1/2⁵=1/32。 小数部分可以将31/32添加到最大整数，因此最大可表示值介于0和22⁷-1+31/32=134 217 727.969之间。

与此同时，最大表示误差计算为（1/S）/2，因此在本例中它等于（1/2÷）/2=1/64=0.015625。 因此，更大的缩放因子允许我们对小数进行更准确的表示，但减少了整数部分的大小，从而减少了可表示值的范围。

正如我们所看到的，我们可以存储的值范围和我们表示的数字的准确性之间存在权衡。

特别是在乘法或除法时，我们可能会遇到溢出。 例如，假设我们的缩放因子为2⁵=32，我们希望将21⁶=65536乘以2⁶=64。 下面的代码试图做到这一点。

功能主()->u32{

设s：u32=32;

令a：u32=65536*s;

令b：u32=64*s;

设结果为：u32=a*b/s;

返回结果;

}

对于定点表示法，我们必须将两个数字乘以一个缩放因子，实际上将221乘以211，然后再用2‰的缩放因子除以。 通过查看说明，我们期望输出代码为22⁷。

然而，当我们看到结果时，我们得到:

[登记册]

r0：u32=0;

C*d的临时结果是232，正好在u32类型的范围之外。 所以我们实际上得到了一个数字溢出，得到了一个不正确的结果。

那么，我们能做些什么呢？ 我们可以对所有类型（变量和输出）使用类型u64而不是类型u32，这些类型可以存储最多2⁶⁴-1的数字。 因此，我们得到了预期的结果22⁷:

[登记册]

r0：u64=134217728;

请记住，我们需要再次除以缩放因子，以便用普通术语解释定点数的结果：22⁷/2⁵=222，这是上述计算21⁶乘以2⁶的结果。

然而，当使用u64时，电路的尺寸从96个限制增加到192个限制，有效地使尺寸增加了一倍。 这会导致验证成本增加，特别是在复杂的应用中。 因此，另一种选择是减少缩放因子，从而潜在地降低数字表示的准确性。

当使用2⁴作为缩放因子而不是仅用于u32类型的2⁵时，我们得到以下结果:

[登记册]

r0：u32=67108864;

此结果等于22‰。 再次，将其除以2‰的缩放因子，我们得到222的预期和正确结果。

该代码通常也适用于负数。 但是，我们需要使用有符号整数类型。 考虑到符号需要一个额外的位，因此对于i32，整数部分的范围计算为+-231-1，其转换为从-2147483648到2147483647的范围。

代码示例

定点格式的两个数字a和b的加法:

功能添加(a:u32,b:u32)->u32{

设结果为：u32=a+b;

返回结果;

}

定点格式的两个数a和b的乘法:

乘法函数(a:u32,b:u32,s:u32)->u32{

让结果：u32=a*b/s;

返回结果;

}

以定点格式划分两个数a和b:

功能划分(a:u32,b:u32,s:u32)->u32{

让结果：u32=s*a/b;

返回结果;

}