Створіть власний Rollup – список проєктів BYOR

Компіляція: План перекладу Denlink

Ви коли-небудь хотіли дізнатися більше про те, як працює Rollup? Теорія хороша, але практичний досвід завжди кращий. На жаль, існуючі проекти не завжди дозволяють легко побачити, що відбувається. Саме тому ми створили BYOR (Build Your Own Rollup). Це суверенний ролап з мінімальною функціональністю, з акцентом на те, щоб зробити код легким для читання та розуміння.

Наша мотивація для цього проєкту полягає в тому, щоб люди, як аутсайдери, так і інсайдери, краще розуміли, чим насправді займаються роллапи навколо нас. Ви можете погратися з розгорнутим BYOR від Holesky або прочитати вихідний код на GitHub.

Що таке BYOR?

Проєкт BYOR є спрощеною версією суверенного зведення. На відміну від оптимістичних доказів зведення з нульовим розголошенням, суверенні зведення не перевіряють державне коріння в Ethereum і покладаються лише на доступність даних і консенсус щодо Ethereum. Це запобігає мостам мінімізації довіри між L1 і BYOR, але значно спрощує код і ідеально підходить для освітніх цілей.

Кодова база складається з трьох програм: смарт-контрактів, вузлів і гаманців. При спільному розгортанні вони дозволяють кінцевим користувачам взаємодіяти з мережею. Цікаво, що стан мережі повністю визначається ончейн-даними, а це означає, що кілька вузлів можуть фактично працювати. Кожен вузол також може публікувати дані незалежно один від одного як секвенсор.

Ось повний список функцій, реалізованих у BYOR:

• Сортування комісій
• Статус публікації в L1 і отримання статусу від L1
• Відмовтеся від недійсних транзакцій
• Перевірити залишок на рахунку
• Надсилання транзакцій
• Перевірити статус транзакції

Використовуйте гаманець

У додатку-гаманці він діє як інтерфейс мережі, де користувачі можуть надсилати транзакції та перевіряти стан своїх рахунків або статус транзакцій. На цільовій сторінці ви побачите огляд, який містить певну статистику про поточний статус зведеного оновлення, а потім статус вашого облікового запису. Швидше за все, є лише одна кнопка для підключення до обраного вами гаманця і є новини про кран токена. Нижче є рядок пошуку, куди ви можете вставити чийсь хеш адреси або транзакції, щоб дослідити поточний стан L2. Нарешті, є два списки транзакцій: перший - це список транзакцій в мемпулі L2, а другий - список транзакцій, опублікованих в L1.

Для початку скористайтеся кнопкою WalletConnect, щоб підключити гаманець. Після підключення ви можете отримати сповіщення про те, що ваш гаманець підключено до неправильної мережі. Якщо ваша програма підтримує перемикання між мережами, натисніть кнопку Switch Network, щоб переключитися на тестову мережу Holesky. В іншому випадку переключіться вручну.

Тепер ви можете надіслати токени комусь, вказавши адресу одержувача, кількість токенів для надсилання та необхідні комісії. Після надсилання додаток гаманця запропонує вам підписати повідомлення. У разі успішного підписання повідомлення надсилається до пулу пам'яті вузла L2, очікуючи публікації на L1. Час, необхідний для включення транзакції в пакетний випуск, може бути різним. Кожні 10 секунд вузол L2 перевіряє наявність контенту для публікації. Транзакції з вищими комісіями надсилаються першими, тому, якщо ви вкажете нижчі комісії та матимете великий трафік транзакцій, ви можете зіткнутися з довгим часом очікування.

Як це працює

Діаграма архітектури зведення ## стек технологій

Кожен компонент ми побудували, використовуючи такі методи:

• 节点: Node.js, Type, tRPC, Postgres, viem, drizzle-orm
• Гаманець: Тип, tRPC, Next.js, WalletConnect

Деталізація коду

Код BYOR розроблений таким чином, щоб його можна було легко зрозуміти, подивившись на кодову базу. Не соромтеся вивчати нашу кодову базу! Спочатку прочитайте README.md, щоб зрозуміти структуру проекту, будь ласка, прочитайте файл ARCHITECTURE.md.

Ось кілька цікавих моментів з коду:

Смарт-контракти

SPDX-License-Identifier: MIT
прагма солідність ^0,8,0;

contract Inputs {
подія BatchAppended(адреса відправника);
function appendBatch(bytes calldata) external {
require(msg.sender == tx.origin);
emit BatchAppended(msg.sender);
}
}

Це єдиний необхідний смарт-контракт. Його назва походить від того, що входи зберігаються у функціях переходу стану. Єдиною метою цього договору є зручне зберігання всіх транзакцій. Серіалізований пакет публікується в цьому смарт-контракті як calldata, і він видає подію BatchAppended з адресою видавця пакета. Хоча ми можемо спроектувати систему таким чином, щоб вона публікувала транзакції безпосередньо в EOA, а не в контракти, дані можуть бути легко отримані через JSON-RPC, видаючи події. Єдиною вимогою до цього смарт-контракту є те, що він повинен бути викликаний не з іншого смарт-контракту, а безпосередньо з EOA.

Схема бази даних

СТВОРЕННЯ ТАБЛИЧНИХ РАХУНКІВ (
текст адреси ПЕРВИННИЙ КЛЮЧ НЕ NULL,
баланс ціле число ЗА ЗАМОВЧУВАННЯМ 0 NOT NULL,
nonce ціле число ТИПОВЕ 0 НЕ NULL
);

СТВОРЕННЯ ТАБЛИЧНИХ транзакцій (
id ціле число,
з тексту NOT NULL,
для тексту NOT NULL,
ціле значення NOT NULL,
nonce ціле число NOT NULL,
fee ціле число NOT NULL,
feeReceipent текст NOT NULL,
l1SubmittedDate ціле число NOT NULL,
хеш-текст NOT NULL
ПЕРВИННИЙ КЛЮЧ(від, не)
);

-- Ця таблиця має один рядок
CREATE TABLE fetcherStates (
chainId ціле число ПЕРВИННИЙ КЛЮЧ НЕ NULL,
lastFetchedBlock ціле число ЗА ЗАМОВЧУВАННЯМ 0 NOT NULL
);

Це вся схема бази даних, яка використовується для зберігання інформації про Rollup. Вам може бути цікаво, навіщо потрібна база даних, якщо всі необхідні дані зберігаються на L1. Хоча це правда, локальне зберігання даних може заощадити час і ресурси, уникаючи повторних придбань. Розглядайте всі дані, що зберігаються в цій схемі, як нотатки про статус, хеші транзакцій та іншу обчислювану інформацію.

Таблиця fetcherStates використовується для відстеження останнього блоку, який ми отримали під час пошуку події BatchAppend. Це корисно, коли вузол вимикається і перезапускається; Він знає, де відновити пошуки.

Функції переходу станів

const DEFAULT_ACCOUNT = { balance: 0, nonce: 0 }

function uteTransaction(state, tx, feeRecipient) {
const fromAccount = getAccount(state, tx.from, DEFAULT_ACCOUNT)
const toAccount = getAccount(state, tx.to, DEFAULT_ACCOUNT)
Крок 1: Оновіть nonce
fromAccount.nonce = tx.nonce
Крок 2: Трансфертна вартість
fromAccount.balance -= tx.value
toAccount.balance += tx.value
Крок 3: Сплатіть комісію
fromAccount.balance -= tx.fee
feeRecipientAccount.balance += tx.fee
}

Функції, показані вище, лежать в основі механізму переходу станів у BYOR. Він передбачає, що транзакція може бути виконана безпечно, з правильним номером і достатнім балансом для здійснення визначеної виплати. Через це припущення всередині цієї функції немає кроків обробки помилок або перевірки. Натомість, ці кроки виконуються перед викликом функції. Кожен стан рахунку зберігається на карті. Якщо обліковий запис ще не існує в цьому зіставленні, для нього буде встановлено значення за замовчуванням, видиме у верхній частині списку коду. З трьох використовуваних рахунків поповнюється нонс і розподіляється залишок.

Підписання транзакції

Підпис транзакції: Ми використовуємо стандарт EIP-712 для підпису введених даних. Це дозволяє нам чітко показувати користувачам, що вони підписують. Як показано вище, під час надсилання транзакції ми можемо відобразити одержувача, суму та комісію у зручному для користувача вигляді.

Подія L1 отримати

function getNewStates() {
const lastBatchBlock = getLastBatchBlock()
const events = getLogs(lastBatchBlock)
const calldata = getCalldata(events)
const timestamps = getTimestamps(events)
const posters = getTransactionPosters(events)
updateLastFetchedBlock(lastBatchBlock)
повернення zip(плакати, позначки часу, дані викликів)
}

Щоб отримати нову подію, ми отримуємо всі події BatchAppended з останнього отриманого блоку з контракту Inputs. Максимальна кількість подій, які ми отримуємо, — це останній фрагмент або останній отриманий фрагмент плюс обмеження розміру пакета. Отримавши всі події, ми витягуємо дані виклику, позначку часу та адресу видавця з кожної транзакції. Оновіть останній блок, який ми отримуємо, до останнього блоку, який ми отримуємо. Потім витягнуті calldata, часова позначка та publisher упаковуються разом і повертаються з функції для подальшої обробки.

Пули пам'яті та їх сортування вартості

function popNHighestFee(txPool, n) {
txPool.sort((a, b) => b.fee - a.fee))
return txPool.splice(0, n)
}

Мемпул — це об'єкт, який керує масивом підписаних транзакцій. Найцікавішим аспектом є те, як він визначає порядок, у якому транзакції розміщуються на L1. Як показано в коді вище, транзакції сортуються відповідно до їх комісій. Це дозволяє медіанній ціні комісії в системі коливатися залежно від активності в мережі.

Навіть якщо ви вкажете високі комісії, транзакції все одно повинні надати дійсний стан, якщо їх потрібно додати до поточного стану. Тому ви не можете надсилати недійсні транзакції лише через високі комісії.

Чи справді BYOR масштабує Ethereum?

Optimism та ZK rollup побудували системи, щоб довести, що опубліковані корені станів узгоджуються з функціями переходу станів та даними, які вони зберігають, але суверенні зведення цього не роблять. Тому нездатність цього типу ролапу масштабувати Ethereum спочатку може здатися нелогічною. Однак це стає розумним, коли ми розуміємо, що інші типи зведень можуть використовувати лише L1, щоб довести, що опублікований корінь стану є правильним. Щоб визначити, правильні дані суверенного зведення чи ні, нам потрібно запустити вузол L1 разом із додатковим програмним забезпеченням для формалізації вузла L2 для виконання функцій переходу стану, тим самим збільшуючи обчислювальне навантаження.

Перспективи на майбутнє

Створення цього проекту стало для нас чудовим навчальним досвідом, і ми сподіваємося, що наші зусилля також будуть цінними для вас. Ми сподіваємося повернутися до BYOR у майбутньому та додати до нього систему захисту від шахрайства. Це зробить його по-справжньому оптимістичним зведенням і ще раз уроком внутрішньої роботи систем, якими ми користуємося щодня.