Створення платформи Express Transaction Credits

TL;DR. Технічний глибокий аналіз того, як платформу EXTC було побудовано на Ethereum ERC-223 у 2018 році: архітектура токенів, виплати з мультипідписом, заблоковані за часом перекази та миттєві кредити під заставу.

Points clés

Проблема проектування: чому ERC-20 був недостатнім. Стандарт ERC-20, запропонований у 2015 році та формалізований у Ethereum Improvement Proposal 20, визначив канонічний інтерфейс взаємозамінних токенів, який забезпечив бум ICO у 2017–2018 роках.
Рішення ERC-223: атомарний переказ із повідомленням. Стандарт ERC-223, запропонований у трекері проблем GitHub для Ethereum EIP, вирішив проблему «тихої втрати» токенів, змінивши вимоги до виконання переказу.
Архітектура контракту EXTC. Контракт токена EXTC був реалізацією на Solidity, структурованою навколо п'яти модулів:.
Механізм миттєвого кредитування под заставу. Примітив кредитування EXTC був найскладнішим компонентом.

Гігантські білі колони .class="img-fluid clearfix"

Резюме / Основні висновки

Основна проблема. ERC-20, домінуючий стандарт токенів Ethereum у 2018 році, мав структурний недолік: токени, переказані безпосередньо на адресу смарт-контракту, безслідно знищувалися, якщо в контракті не було обробника. Будь-яка платіжна платформа, побудована на ERC-20, успадковувала цей ризик (Ethereum EIPs).

ERC-223 як виправлення. ERC-223 вимагав від контрактів-отримувачів реалізації функції tokenFallback(address, uint, bytes). У разі її відсутності переказ атомарно скасовувався. Жоден токен не міг бути безслідно втрачений (Ethereum EIPs GitHub).

П'ять примітивів контракту EXTC. Ідентичність токена (назва, символ, 18-значна точність), фіксована пропозиція, переказ, сумісний з ERC-223, корпоративні виплати з мультипідписом та постійні доручення, заблоковані за часом на основі висоти блоку.

Механізм кредитування під заставу. Позичальники блокували токени EXTC на ескроу-рахунку контракту; контракт атомарно виділяв кошти кредиту після отримання застави, без затримок на андеррайтинг або схвалення кредитного комітету.

Що виявив експеримент щодо обмежень Ethereum. При пропускній здатності основної мережі ~15 TPS і вартості газу $0,10–$1,00 за транзакцію на піку в січні 2018 року платіжна мережа, що обробляє навіть обсяги на рівні грошових переказів, була економічно та технічно неможливою у публічній мережі Ethereum без інфраструктури другого рівня (Layer-2).

Проблема проектування: чому ERC-20 був недостатнім

Стандарт ERC-20, запропонований у 2015 році та формалізований у Ethereum Improvement Proposal 20, визначив канонічний інтерфейс взаємозамінних токенів, який забезпечив бум ICO у 2017–2018 роках. Його шість основних функцій — totalSupply, balanceOf, transfer, transferFrom, approve та allowance — були достатніми для простого випуску та обміну токенів.

Однак для платіжної платформи ERC-20 мав критичний для розгортання недолік. Функція transfer(address _to, uint256 _value) переміщувала токени на будь-яку адресу, включаючи адреси контрактів, без запуску будь-якого коду в контракті-отримувачі. Контракт, який не був спеціально запрограмований для відстеження вхідних переказів ERC-20, не мав можливості їх виявити. Токени, надіслані таким чином, залишалися заблокованими назавжди, без жодного механізму відновлення.

Спільнота Ethereum оцінила, що до середини 2018 року за цим механізмом було безповоротно втрачено десятки мільйонів доларів у токенах ERC-20. Створення платіжної платформи, де перекази могли безслідно зазнавати невдачі та знищувати кошти користувачів, було неприпустимим.

Рішення ERC-223: атомарний переказ із повідомленням

Стандарт ERC-223, запропонований у трекері проблем GitHub для Ethereum EIP, вирішив проблему «тихої втрати» токенів, змінивши вимоги до виконання переказу. Відповідно до ERC-223, функція transfer(address _to, uint256 _value, bytes _data) перевіряла, чи містить адреса отримувача код контракту. Якщо так, переказ викликав _to.tokenFallback(address _from, uint256 _value, bytes _data).

Критична властивість: якщо контракт-отримувач не реалізовував функцію tokenFallback, вся транзакція переказу скасовувалася. Жодні токени не списувалися з балансу відправника. Жодні токени не блокувалися. Переказ був атомарним — він або завершувався виконанням коду отримувача, або повністю скасовувався без зміни стану.

Для EXTC це означало:

Оплата на смарт-контракти була безпечною за дизайном. Контракти ескроу, гаманці з мультипідписом та контракти кредитування могли отримувати токени EXTC без будь-якого ризику безповоротної втрати коштів.
Поле _data дозволяло передавати розширені метадані платежу. Корисне навантаження в байтах могло містити посилання на рахунки-фактури, коди маршрутизації або підтвердження відповідності вимогам — інформацію, яку простий переказ ERC-20 передати не міг.
Витрати на газ були незначно вищими. Виклик tokenFallback додавав приблизно 2 000–5 000 одиниць газу за переказ, що було незначними додатковими витратами за цінами на газ 2018 року.

Архітектура контракту EXTC

Контракт токена EXTC був реалізацією на Solidity, структурованою навколо п'яти модулів:

1. Ідентичність токена

string public name = "Express Transaction Credits";
string public symbol = "EXTC";
uint8 public decimals = 18;

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

2. Фіксована загальна пропозиція

Загальна пропозиція встановлювалася під час розгортання контракту і не могла бути збільшена за рахунок наступних випусків (мінтингу). Таке конструктивне рішення зробило EXTC дефляційним: будь-які токени, назавжди вилучені з обігу через незворотні операції спалювання, зменшували пропозицію без можливості заміщення. Модель із фіксованою пропозицією була стандартною в дизайні платіжних токенів 2018 року, відображаючи сформоване під впливом Bitcoin припущення, що дефляційний тиск є корисною властивістю для засобу обміну.

3. Баланс та переказ, сумісні з ERC-223

Основна функція переказу реалізовувала повний інтерфейс ERC-223. Внутрішні відображення балансів відстежували активи кожної адреси. Допоміжна функція isContract(address) відрізняла адреси EOA (зовнішньо керовані облікові записи) від адрес контрактів, щоб визначити, чи потрібно викликати tokenFallback.

4. Корпоративні виплати з мультипідписом

Робочі процеси корпоративних платежів вимагали спільної авторизації: жоден підписант не міг одноосібно ініціювати виплату понад визначений поріг. Контракт EXTC реалізовував схему мультипідпису «два з N»:

Визначений ініціатор пропонував переказ, вказуючи отримувача, суму та одноразовий номер (nonce).
Співпідписант підтверджував цей nonce.
Переказ виконувався лише після того, як обидва підписи були зафіксовані в мережі (ончейн).

Це усунуло ризик єдиної точки відмови для корпоративних рахунків, зберігаючи весь процес авторизації ончейн та відкритим для аудиту без посередництва клірингової палати.

5. Постійні доручення, заблоковані за часом на основі висоти блоку

Регулярні платежі — зарплати, підписки, планові погашення кредитів — вимагали примітиву постійного доручення. EXTC реалізував це як часове блокування (time-lock): запис про переказ зберігався в контракт з параметром releaseBlock. Переказ не міг бути виконаний, поки висота блоку Ethereum не досягне значення releaseBlock.

Висота блоку як показник часу була прагматичним вибором у 2018 році. Ethereum орієнтувався на 15-секундний інтервал між блоками, що робило висоту блоку досить надійним показником реального часу в межах кількох хвилин. Абсолютні мітки часу (block.timestamp) були доступні, але піддавалися маніпуляціям з боку майнерів у межах ±900-секундного вікна, що робило висоту блоку безпечнішим орієнтиром для фінансових контрактів.

Механізм миттєвого кредитування под заставу

Примітив кредитування EXTC був найскладнішим компонентом. Конструкція:

Позичальник блокує заставу. Позичальник викликав lockCollateral(uint256 _collateralAmount), переказуючи токени EXTC на ескроу-рахунок контракту кредитування через tokenFallback ERC-223.
Перевірка співвідношення кредиту до застави (LTV). Контракт зчитував попередньо налаштований коефіцієнт LTV (наприклад, 50%) і розраховував максимальну суму кредиту під заблоковану заставу.
Атомарна виплата кредиту. Якщо застава відповідала мінімальному порогу, контракт негайно переказував суму кредиту на адресу позичальника. Жодних черг на андеррайтинг, жодних кредитних комітетів, жодних затримок розрахунків.
Погашення та повернення. Після погашення — основної суми плюс фіксована відсоткова ставка — контракт повертав заставу позичальнику. Несплата до настання releaseBlock викликала автоматичну ліквідацію: контракт переказував заставу на визначену адресу кредитора.

Весь процес забезпечувався кодом контракту. Жодній із сторін не потрібно було довіряти іншій або покладатися на посередника для виконання умов.

Що виявив експеримент

Архітектура контракту EXTC була технічно узгодженою. ERC-223 вирішив найсерйозніший недолік безпеки ERC-20. Примітиви мультипідпису та часового блокування безпосередньо відповідали реальним корпоративним робочим процесам платежів. Механізм кредитування під заставу продемонстрував, що забезпечене кредитування може бути повністю автоматизованим та самовиконуваним ончейн.

На практиці виявилися два обмеження:

Вартість газу. На піку в січні 2018 року ціни на газ в Ethereum досягали 50–100 gwei, через що вартість одного переказу токенів ERC-223 становила $0,50–$2,00. Для мікроплатежів або грошових переказів на суму $10–$50 такі комісії були непомірними.

Пропускна здатність. Ліміт газу на блок в основній мережі Ethereum на початку 2018 року становив приблизно 8 мільйонів одиниць газу. Переказ ERC-223 споживав орієнтовно 50 000–80 000 газу. Таким чином, мережа могла обробляти приблизно 100–160 переказів токенів EXTC за блок, або приблизно 7–11 транзакцій на секунду при 15-секундному інтервалі між блоками. Масштаб платіжної мережі — сотні або тисячі транзакцій на секунду — був недосяжним у публічній мережі Ethereum без інфраструктури другого рівня (Layer-2), яка на той час ще не існувала в робочому вигляді.

Це були інфраструктурні обмеження, а не недоліки проектування EXTC. Логіка контракту була правильною. Базовий блокчейн ще не міг підтримувати обсяг платежів у масштабах фінансової індустрії.

Ідеї, що дійшли до виробництва

Кілька шаблонів проектування з EXTC були підтверджені подальшим розвитком:

Атомарний переказ токенів із повідомленням отримувача — ключова властивість ERC-223 — став основою для ERC-777 (2019), який розширив модель повідомлень і згодом був інтегрований у протоколи кредитування DeFi. Шаблон tokenFallback зустрічається у всій сучасній архітектурі DeFi.

Авторизація з мультипідписом для корпоративних виплат — шаблон, який вимагає кількох ончейн-підписів перед виконанням — став стандартною моделлю для управління казначейством DAO та інституційних рішень для зберігання активів. Проект Gnosis Safe, запущений у 2018 році, популяризував цей шаблон у великих масштабах.

Миттєві кредити під заставу без посередників — механізм блокування застави на ескроу-рахунку та атомарного виділення коштів кредиту — є фундаментальним дизайном протоколів кредитування DeFi, таких як Compound (2018) та Aave (2020).

Часові блокування за висотою блоку для запланованих платежів — шаблон кодування часу майбутнього виконання в контракт — використовується в контрактах вестингу токенів, відкладених пропозиціях з управління та дизайні оракулів середньозваженої за часом ціни (TWAP) у всій екосистемі DeFi.

Експеримент EXTC не досяг промислового масштабу. Інфраструктура, необхідна для життєздатності цієї концепції, дозрівала ще три-п'ять років. Питання дизайну, які він порушував, були правильними для 2018 року.

Часті запитання

Чому ERC-223 так і не став домінуючим стандартом токенів, незважаючи на виправлення недоліку ERC-20?

ERC-223 вимагав від контрактів-отримувачів реалізації tokenFallback, що порушувало зворотну сумісність із тисячами вже розгорнутих контрактів для токенів ERC-20. Наявна екосистема ERC-20 була занадто великою для міграції. Наступні пропозиції — зокрема ERC-777 та ERC-1363 — вирішували ту саму проблему з іншими компромісами щодо сумісності, але ERC-20 залишився домінуючим завдяки поєднанню мережевих ефектів та впровадженню шаблонів обгорнутих (wrapped) токенів, які дозволяли уникати сценарію тихої втрати.

Що сталося з токеном та платформою EXTC?

EXTC був проектом перевірки концепції (proof-of-concept) та раннім дослідницьким проектом 2018 року. Ширший ринок ICO та платіжних токенів різко скоротився протягом 2018–2019 років, коли стали очевидними обмеження масштабованості Ethereum та регуляторна невизначеність. Ідеї, закладені в дизайн EXTC, знову з'явилися у пізніших протоколах, які отримали доступ до інфраструктури другого рівня (Layer-2), кращих інструментів розробки та більш чітких регуляторних рамок.

Як модель кредитування під заставу EXTC порівнюється з сучасними DeFi-протоколами на кшталт Aave?

Основний механізм однаковий: заблокувати заставу, отримати кредит відповідно до коефіцієнта LTV, погасити його або піддатися ліквідації. Відмінності полягають у наступному: (1) сучасні DeFi-протоколи використовують цінові потоки оракулів для динамічного LTV замість фіксованих коефіцієнтів; (2) вони використовують алгоритмічні відсоткові ставки, які реагують на рівень використання пулу; (3) вони працюють у мережах другого рівня (Layer-2) з витратами на газ у 10–100 разів нижчими, ніж в основній мережі 2018 року; (4) Aave та Compound пройшли формальні аудити безпеки та утримували мільярди доларів ліквідності, надаючи емпіричне підтвердження надійності базової моделі.

Якими були обмеження версії Solidity на початку 2018 року?

Контракт EXTC був написаний для Solidity 0.4.x, домінуючої версії на початку 2018 року. У Solidity 0.4 бракувало багатьох функцій безпеки, представлених у пізніших версіях: автоматичної перевірки переповнення цілих чисел (додано в 0.8.0), require/revert з повідомленнями про помилки (обмежено в 0.4) та явного визначення видимості функцій (за замовчуванням у 0.4 вона була public). Контракт покладався на бібліотеку SafeMath від OpenZeppelin для захисту від переповнення, що було поширеним шаблоном до того, як компілятор почав контролювати це нативно.

Джерела

Ethereum Foundation, (2015). EIP-20: Token Standard ⧉.
Dexaran, Ethereum GitHub, (2017). ERC-223 Token Standard Proposal ⧉.
OpenZeppelin, (2018). OpenZeppelin Contracts — SafeMath ⧉.
Ethereum Foundation, (2014). Ethereum Whitepaper ⧉.

Останній перегляд: 2026-06-23.

```

Останній перегляд 2026-07-16.

Перевидати цю статтю

Створення платформи Express Transaction Credits — Sebastien Rousseau

Технічний глибокий аналіз того, як платформу EXTC було побудовано на Ethereum ERC-223 у 2018 році: архітектура токенів, виплати з мультипідписом, заблоковані за часом перекази та миттєві кредити під заставу.

Ця стаття поширюється за ліцензією Creative Commons Attribution 4.0 International. Перевидання вимагає посилання на канонічну URL-адресу.

Створення платформи Express Transaction Credits — Sebastien Rousseau

Технічний глибокий аналіз того, як платформу EXTC було побудовано на Ethereum ERC-223 у 2018 році: архітектура токенів, виплати з мультипідписом, заблоковані за часом перекази та миттєві кредити під заставу.

Originally published at https://sebastienrousseau.com/uk/2018-02-15-stvorennia-platformy-express-transaction-credits/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER