Чтобы сделать новую модель немного более понятной, давайте сравним ее с двумя наиболее распространенными на сегодняшний день моделями хранения данных, которыми являются 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 позволяет создавать накопительные пакеты для конкретных приложений без необходимости запускать дополнительные цепочки блоков или заботиться о какой-либо лишней инфраструктуре, такой как мосты. По сути, он получает все преимущества от масштабирования без каких-либо неотъемлемых рисков, связанных с накоплением.