Биткойн OP_RETURN Байт-код
BOB (биткойн OP_RETURN Bytecode) - это новый формат сериализации транзакций для работы с биткойн-транзакциями, особенно OP_RETURN.
До сих пор все существующие системы Планария основывались на формате сериализации под названием TXO.
BOB - это новая, модифицированная версия TXO, которая использует метафору абстрактной машины, где инструкции записываются на лентах, состоящих из ячеек, где каждая ячейка содержит единственный вызов атомарной процедуры.
Это формат сериализации биткойн-транзакций, который принципиально перестает рассматривать OP_RETURN данные как простой поток данных, а как фактические вызовы процедур в виртуальной операционной системе.
Он называется «OP_RETURN Байт-код», потому что обрабатывает сценарии OP_RETURN как вызовы процедур, что значительно упрощает создание собственной операционной системы протокола на биткойне.
Вот предварительный просмотр новой структуры данных:
А вот пример запроса, в котором используется эта новая схема:
А ниже приведен пример того, как выглядит структура BOB, когда вы делаете вышеуказанный запрос (первая лента - это Metalens с 2 ячейками, а вторая - Twetch с 3 ячейками):
Вы можете попробовать запрос здесь:
Прежде чем мы начнем, вот BOB, первая машина Planaria, использующая этот формат. Поиграйте с этим, прежде чем читать дальше:
BOB - это форк Neon Genesis, так что вы должны чувствовать себя как дома. Он сканирует тот же набор транзакций, что и Neon Genesis, но только в другой структуре. Единственная разница заключается в массивах in и out, внутренняя структура которых была переработана в соответствии с новой философией, приняв метафору tape + cell.
Благодарности
Особая благодарность: jolon, libitix, breavyn за идеи, отзывы и обсуждения в Atlantis.
Оглавление
Эта статья будет охватывать:
- TXO
- BitCom
- BitCom Pipeline
- Потребность в новом формате
- BOB: Биткойн OP_RETURN Байт-код
- ЛПП Планария
- Заключение
1. TXO
Чтобы понять, почему необходима новая схема, нам сначала нужно понять, как работает существующая схема. В этом разделе объясняется текущее состояние систем, связанных с Planaria.
В основе Planaria лежит формат сериализации транзакций под названием TXO.
TXO был фундаментальным строительным блоком для многих проектов, над которыми я работал, таких как BitDB, BitSocket, Planaria, Neon Planaria, Bitbus, Eventchain и т. Д.
Вкратце поясним: формат TXO принимает необработанную одномерную биткойн-транзакцию и превращает ее в двухмерный объект JSON, который затем может быть сохранен в базе данных документов, использован как событие или отфильтрован. с библиотекой обработки потоков JSON в реальном времени.
Основное нововведение TXO заключается в подходе к разделению всех отдельных push-данных для индексации вместо того, чтобы рассматривать транзакции как одномерные денежные переводы от A к B.
Общая схема вместе с соответствующим мощным языком запросов (Bitquery) сделала ее привлекательной для использования во многих приложениях Биткойн.
Вот как выглядит биткойн-транзакция в формате TXO с переводом:
Соответствующая часть здесь - это массив out. Каждый элемент в массиве out представляет выходной сценарий.
Сценарий вывода имеет атрибуты с префиксом b и атрибуты с префиксом s. Они представляют их последовательность push-данных. Атрибуты с префиксом b представляют версию push-данных в кодировке base64, а атрибуты с префиксом s представляют версию тех же push-данных в кодировке UTF8. Например, b0 означает первые (позиционный индекс 0) push-данные в кодировке base64, а s2 означает третьи (позиционный индекс 2) push-данные в кодировке UTF.
Этот формат позволяет легко запрашивать и фильтровать различные шаблоны транзакций в цепочке блоков, после чего программисты могут обрабатывать данные для создания своего собственного конечного автомата. Допустим, мы хотим запрашивать все транзакции с помощью выходного скрипта, который выглядит так:
OP_RETURN 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [DATA] [MEDIA_TYPE] [ENCODING] [FILENAME]
Кроме того, мы можем захотеть выбрать только поле [FILENAME] набора результатов. Используя Bitquery, вы можете просто запросить:
{
"v": 3,
"q": {
"find": {
"out.s1": "19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut"
},
"project": {
"out.s5": 1
}
}
}
Вы можете сами опробовать этот запрос здесь:
Так сегодня работает большинство систем Planaria.
2. BitCom
В приведенном выше примере вы могли заметить, что первые push-данные после OP_RETURN - это биткойн-адрес 19HxigV4QyBvetHpQVcUEQyq1pzZVdoAut. Это называется «префиксом протокола». Добавляя к транзакциям этот уникальный адрес, вы помечаете их, чтобы они интерпретировались определенным образом. Без этих префиксов было бы трудно сказать, как следует интерпретировать каждый шаблон транзакции, поскольку каждый протокол приложения имеет свое правило для интерпретации выходной последовательности.
Раньше люди просто придумывали свои собственные произвольные префиксы и публиковали их в централизованном реестре, чтобы избежать конфликта пространств имен. Однако это было слишком централизованным и не масштабируемым, потому что разработчикам всегда приходилось получать одобрение какого-то комитета.
Вот почему родился BitCom. С BitCom вы просто генерируете биткойн-адрес, а затем используете его в качестве префикса протокола. Поскольку случайно сгенерированные биткойн-адреса могут считаться достаточно уникальными, вы можете использовать это для уникальной идентификации протоколов. Кроме того, поскольку это биткойн-адрес, вы можете использовать соответствующий закрытый ключ, чтобы доказать, что вы являетесь создателем протокола. Наконец, публикуя транзакцию, содержащую префикс Bitcom, отправленную с того же адреса, вы навсегда подписываете и подтверждаете создание своего протокола в цепочке блоков.
Вы можете узнать больше о BitCom здесь:
Вы также можете проверить каталог децентрализованных протоколов для протоколов, поддерживаемых BitCom, здесь:
3. BitCom Pipeline
BitCom - это «протокол протокола», протокол для определения структуры протокола.
Это означает, что речь идет не только об уникальных идентификаторах префиксов, но и для определения способов взаимодействия нескольких протоколов друг с другом.
Еще в январе была дискуссия о реализации структуры, подобной Unix Pipeline, для протоколов, чтобы несколько протоколов могли свободно взаимодействовать друг с другом.
Тогда это была просто идея, но с тех пор люди подхватили ее и начали использовать, и сегодня этот тип протокола mashup стал распространенным во многих приложениях Биткойн.
Например, публикация на Twetch включает 3 протокола, разделенных вертикальной чертой (|). И многие другие приложения (например, TonicPow, основатели которого фактически создали Протокол магических атрибутов и Протокол идентификации автора) в настоящее время работают на конвейере OP_RETURN.
B:// | Magic Attribute Protocol | Author Identity Protocol
Вы можете узнать больше о том, как все началось здесь:
4. Потребность в новом формате
Органическое внедрение конвейера BitCom стало большим шагом вперед для построения сложных транзакций OP_RETURN, но также представило большую проблему с точки зрения того, как фильтровать цепочку блоков для различных шаблонов транзакций. В частности,
- BitCom изначально был разработан с предположением, что есть только ОДИН вызов процедуры на
OP_RETURNвыход. - Но с конвейером BitCom теперь несколько вызовов процедур (например,
B://,Magic Attribute Protocol,Author Identity Protocol) могут сосуществовать в рамках одной команды, связывая вызовы процедур вместе как одну атомарную единицу. .
Например, давайте рассмотрим простой B:// пример БЕЗ конвейера:
Благодаря фиксированной структуре мы можем легко запрашивать, фильтровать и обрабатывать транзакции с помощью Bitquery. Поскольку мы ищем адрес 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut в позиционном индексе 2, мы можем запросить:
{
"v": 3,
"q": {
"find": {
"out.s2": "19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut"
}
}
}
И он даст нам все соответствующие «команды», необходимые для запуска конечного автомата.
Но конвейер BitCom меняет правила игры. Например, давайте посмотрим на другой пример, где B:// используется вместе с другим протоколом:
Теперь все сложнее. В одной команде есть два вызова процедур, соединенных конвейером |.
Как это отфильтровать? Раньше было достаточно фильтрации "s2": "19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut", но на этот раз "19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut" существует в другой позиции в конвейере. Теперь нам нужно еще принять во внимание "s6": "19HxigV4QyBvetHpQVcUEQyq1pzZVdoAut"
{
"v": 3,
"q": {
"find": {
"$or": [
{ "s2": "19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut" },
{ "s6": "19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut" }
]
}
}
}
Хорошо, хорошая работа, но что, если есть три протокола, как этот?
Теперь у нас есть 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut в индексе 11, поэтому я думаю, мы добавим еще одно условие к $or, верно?
{
"v": 3,
"q": {
"find": {
"$or": [
{ "s2": "19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut" },
{ "s6": "19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut" },
{ "s11": "19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut" }
]
}
}
}
Но в этот момент мы начинаем понимать, что это неустойчиво, может быть слишком много комбинаций.
И это даже до того, как мы рассмотрим гораздо более сложную проблему протоколов динамической длины, таких как Magic Attribute Protocol, где протокол может иметь переменное количество аргументов. С протоколами переменной длины мы больше не можем даже вычислить индекс, и метод $or его вообще не обработает.
TXO не обладает достаточной выразительностью, чтобы справиться с этими проблемами.
Нам нужен формат, достаточно выразительный, чтобы создавать все виды протокольных операционных систем.
5. BOB: биткойн OP_RETURN байт-код
BOB - это схема структуры данных для решения проблем, описанных выше.
BOB рассматривает OP_RETURN выходы не просто как данные, а как вызовы процедур.
В частности, мы применяем подход «позиционной ассоциации», используя первые данные push в качестве Procedure_Name, а остальную часть списка данных push в качестве параметров.
Итак, как мы реализуем это в биткойнах? Чтобы понять это, давайте начнем с абстрактного компьютера и продолжим.
Если вы изучали информатику, то знаете, что можно создать полноценный абстрактный компьютер, используя магнитные ленты. И это то, что мы собираемся здесь делать. Мы смотрим на каждый сценарий ввода и вывода Биткойна как на одну полосу ленты, с которой мы будем запускать вычисления.
В этой модели вычислений «ячейка» - это единая исполнительная единица. Мы могли бы думать об этом как об одном «вызове процедуры» (например, B: //, Magic Attribute Protocol и Author Identity Protocol). Давайте посмотрим на пример:
Используя метафору «лента» и «ячейка», мы получаем одну «ленту» с 4 ячейками. Мы можем визуализировать это следующим образом (трубы исключены из BOB):
Каждая ячейка представляет собой отдельный вызов процедуры. Как и в любой операционной системе, у каждого процесса есть адрес. По совпадению, BitCom буквально использует адрес (биткойн-адрес) для представления вызовов процедур.
Каждая ячейка также содержит дополнительные аргументы после адреса и локальной области выполнения. Например, ячейка 2 имеет следующие аргументы: SET, name и Heuristically Programmed ALgorithmic Computer.
Немного изменив соглашение TXO о b как base64 и s как UTF8, мы можем представить приведенную выше диаграмму как абстрактное синтаксическое дерево:
tape := [
{
cell: [
{op:0,ops:"OP_0","ii":0,"i":0},
{op:106,ops:"OP_RETURN","ii":1,"i":1}
]
},
{
cell: [
{s:"19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut","ii":2,"i":0},
{b:<file-base64>,s: <file-utf8>,"ii":3,"i":1},
{b:<mediatype-base64>,s:<mediatype-utf8>,"ii":4,"i":2},
{b:<encoding-base64>,s:<encoding-utf8>,"ii":5,"i":3},
{b:<filename-base64>,s:<filename-utf8>,"ii":6,"i":4}
]
},
{
cell: [
{s:"1PuQa7K62MiKCtssSLKy1kh56WWU7MtUR5","ii":8,"i":0},
{s:"name","ii":9,"i":1},
{s:"Heuristically Programmed ALgorithmic Computer","ii":10,"i":2}
]
},
{
cell: [
{s:"15PciHG22SNLQJXMoSUaWVi7WSqc7hCfva","ii":12,"i":0},
{s:"BITCOIN_ECDSA","ii":13,"i":1},
{s:...,"ii":14,"i":2}
]
}
]
И в этом суть БОБа. Он хранит входные и выходные данные транзакций в формате «лента + ячейка». Ознакомьтесь с этим запросом, чтобы увидеть фактические данные:
Есть несколько заметных отличий от TXO:
- Каждая процедура локально привязана к ячейке: вместо одной непрерывной ленты, лента разбивается на ячейки, каждая из которых содержит один вызов процедуры (например, B: //, Magic Attribute Protocol или Протокол идентификации автора) с использованием вертикальных черт
|в качестве разделителей. Это означает, что у вас есть не только позиция push-данных в глобальной области видимости, но и позиция внутри локальной области. - Массивы вместо атрибутов: больше никаких
b0,b1и т. д. Вместо этого эти атрибуты хранятся в виде элементов в массивах с именемcell, которые содержат объекты push-данных с атрибутамиb,sи т. д. Потому что запускать экзистенциальные запросы несложно, что раньше было невозможно. - Более компактный: в TXO раньше был атрибут под названием «str», который содержал полное строковое представление каждой транзакции. Это было лишним, и я не знаю, чтобы люди когда-либо его использовали, но он занимал все пространство, поэтому этот атрибут был удален.
- Локальная область действия: каждый элемент имеет новый атрибут с именем
i, который представляет локальный позиционный индекс, в котором он появляется в родительской последовательности. Например, элементcellсiиз 2 означает, что это третий элемент в ячейке. - Глобальная область: элемент ячейки также имеет атрибут с именем
ii, который представляет глобальный позиционный индекс. Например, то, что раньше былоs13в формате TXO, будет иметьiiиз 13 в BOB.
И так же, как TXO, этот формат структуры данных может храниться в базе данных документов, а также фильтроваться в реальном времени.
6. ЛПП Планария
Давайте рассмотрим пару примеров запросов, чтобы понять, что позволяет эта новая схема.
1. Фильтровать префикс протокола В ЛЮБОМ месте конвейера
Допустим, мы хотели запросить: «Найти все транзакции BitCom с префиксом протокола 1PuQa7K62MiKCtssSLKy1kh56WWU7MtUR5».
Как мы видели выше, это становится чрезвычайно сложным, и нам пришлось прибегнуть к $or запросам с жестко заданными позициями, которые не масштабируются. Однако с BOB этот запрос становится чрезвычайно простым.
Все, что вам нужно сделать, это запросить массив tape.cell на предмет существования. Вам даже не нужно указывать должность.
Вот запрос:
{
"v": 3,
"q": {
"find": {
"out.tape.cell.s": "1PuQa7K62MiKCtssSLKy1kh56WWU7MtUR5"
},
"limit": 2
}
}
Спросите БОБА:
Этот единственный запрос может найти 1PuQa7K62MiKCtssSLKy1kh56WWU7MtUR5 независимо от того, где он отображается во всем конвейере. Обратите внимание, что запрос даже не включает позицию. Он просто спрашивает, существует ли ценность где-нибудь.
2. Позиционный запрос с локальной областью действия
Поскольку у нас есть доступ к позиционному индексу каждого push-данных В пределах их локальной области выполнения, нам больше не нужно беспокоиться о глобальном индексе позиции. Все, что нас волнует, - это индекс локальной области (ячейки).
Если мы хотим найти вхождение «1PuQa7K62MiKCtssSLKy1kh56WWU7MtUR5» в качестве первого элемента собственной ячейки, нам просто нужно отфильтровать ячейки, которые одновременно соответствуют i 0 и s 1PuQa7K62MiKCtssSLKy1kh56WWU7, используя _Mt62UR7.
{
"v": 3,
"q": {
"find": {
"out.tape.cell": {
"$elemMatch": {
"i": 0,
"s": "1PuQa7K62MiKCtssSLKy1kh56WWU7MtUR5"
}
}
},
"project": {
"out.tape.cell.s": 1
},
"limit": 5
},
"r": {
"f": "[ .[] | .out[0].tape[] | { cell1: .cell } ]"
}
}
Спросите БОБА:
3. OP_RETURN против OP_FALSE OP_RETURN перестает быть проблемой.
Такой подход к локальному анализу дает нам отличный побочный эффект. Если вы используете BOB, проблема OP_RETURN vs. OP_FALSE OP_RETURN перестает быть проблемой.
Если вы не знали об этом, все OP_RETURN разработчики протоколов должны помнить одну вещь: в 2020 году OP_RETURN перейдет от бессмысленного кода операции, используемого в основном для присоединения произвольных данных, к реальной конструкции языка программирования.
Он восходит к оригинальному дизайну Биткойна, где теперь является фактическим заявлением о «возврате». Это откроет двери для многих интересных функций, потому что теперь функции могут возвращать значения.
Но это также означает, что могут быть уязвимости, если вы не полностью понимаете последствия. Вот почему рекомендуется, чтобы разработчики начали использовать OP_FALSE OP_RETURN вместо просто OP_RETURN. Подробнее об этом можно прочитать здесь:
В любом случае, если бы мы хотели поддерживать как устаревшие OP_RETURN, так и новые OP_FALSE OP_RETURN параметры, используя существующие узлы Planaria, такие как Genesis и Babel, нам пришлось бы написать $or запрос, учитывающий оба случая (потому что теперь OP_RETURN может отображаться как первый код операции, но также второй после OP_FALSE)
Но поскольку BOB разбивает ленту на несколько ячеек и сохраняет позиционный индекс локальной области, вам больше не нужно беспокоиться об этом, потому что ваши запросы будут относиться к локальной области, а не к глобальной. Также потому, что вы можете выполнять запросы, даже не беспокоясь о позиционном индексе.
Чтобы уточнить, следующий запрос вернет точно такой же результат, независимо от того, начинается ли ваш вывод с OP_RETURN или OP_FALSE OP_RETURN, потому что в обоих случаях они будут принадлежать их собственной ячейке и не будут влиять на локальное положение «1PuQa7K62MiKCtssSLKy1kh56WWU7MtUR5» в пределах своей собственной ячейки. .
{
"v": 3,
"q": {
"find": {
"out.tape.cell": {
"$elemMatch": {
"i": 0,
"s": "1PuQa7K62MiKCtssSLKy1kh56WWU7MtUR5"
}
}
}
}
}
4. Запрос глобального позиционного индекса
Хотя запрос локального позиционного индекса очень полезен, это не означает, что глобальный позиционный индекс исчез, вы все равно можете запросить по глобальному индексу.
Если вы использовали следующий запрос (ищите индекс 1):
{
"v": 3,
"q": {
"find": {
"out.s1": "19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut"
},
"limit": 10
}
}
Теперь вы можете сделать следующее, потому что у каждого push-данных в ячейке есть дополнительный атрибут с именем i, который хранит глобальный позиционный индекс:
{
"v": 3,
"q": {
"find": {
"out.tape.cell":{
"$elemMatch": {
"ii": 1,
"s": "19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut"
}
}
},
"limit": 10
}
}
5. Специальный атрибут OPCODE, понятный человеку.
В 2020 году все ограничения скриптов исчезнут, и мы наконец сможем использовать биткойн-скрипт в качестве реального языка программирования.
Я уверен, что возникнет необходимость в запросе и фильтрации этих кодов операций NON-OP_RETURN. До сих пор коды операций хранились с атрибутами b. Это было не самое чистое дизайнерское решение, потому что это означало, что b переменные можно было использовать как для base64 закодированных push-данных, так и для хранения кодов операций. Например, код операции OP_RETURN мог выглядеть так:
{
b0: {
"op": 106
},
..
}
но в то же время он использовался для хранения base64, например:
{
b0: {
"op": 106
},
"b1": "MTlIeGlnVjRReUJ2M3RIcFFWY1VFUXlxMXB6WlZkb0F1dA",
"s1": "19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut",
..
}
Это сбивает с толку, поэтому в этой новой схеме есть два дополнительных атрибута: op (для номера кода операции) и ops (для строки кода операции). Вот пример:
[
{
"cell": [
{
"op": 0,
"ops": "OP_0",
"ii": 0,
"i": 0
},
{
"op": 106,
"ops": "OP_RETURN",
"ii": 1,
"i": 1
}
]
},
..
]
Это делает его более читабельным, а также более последовательным правилом. Теперь правило именования атрибутов простое:
b: push-данные в кодировке base64s: push-данные в кодировке UTF8op: номер кода операцииops: строка кода операции
Сегодня у нас нет доступа ко многим различным типам кодов операций, но интересно просто представить, что в ближайшем будущем мы сможем делать такие запросы:
{
"v": 3,
"q": {
"find": {
"out.tape.cell.ops": "OP_CODESEPARATOR"
}
}
}
7. Заключение
Поскольку BOB является форматом сериализации и просто слишком удобен для работы со сценариями OP_RETURN, вы, вероятно, начнете видеть это в других будущих конечных точках Planaria, а также в других связанных системах, таких как Bitbus и т. Д.
Это первая версия BOB, и она будет продолжать развиваться в зависимости от моделей использования и отзывов, поэтому не стесняйтесь присылать свои вопросы и отзывы.
Попробуйте Боб:
Задавать вопросы:
1. Присоединяйтесь к каналу #planaria в Атлантиде.
2. Найдите меня в Twitter: https://twitter.com/_unwriter
