Sebastien Rousseau
Contact ›

The making of the Express Transaction Credits Platform

Arhitectura tokenurilor, plăți cu semnături multiple și transferuri cu blocare temporală pe Ethereum în 2018.

9 min de citit
Banner for: The making of the Express Transaction Credits Platform

Giant white pillars.class="img-fluid clearfix"

Rezumat executiv / Concluzii cheie

  • Problema de bază. ERC-20, standardul dominant de token Ethereum în 2018, avea un defect structural: tokenurile transferate direct la adresa unui smart contract erau distruse silențios dacă contractul nu avea un handler. Orice platformă de plată construită pe ERC-20 moștenea acel risc (Ethereum EIPs).
  • ERC-223 ca soluție. ERC-223 impunea contractelor destinatare să implementeze o funcție tokenFallback(address, uint, bytes). Dacă era absentă, transferul se anula atomic. Niciun token nu putea fi pierdut silențios (Ethereum EIPs GitHub).
  • Cele cinci primitive ale contractului EXTC. Identitatea tokenului (name, symbol, precizie de 18 zecimale), ofertă fixă, transfer conform ERC-223, disbursare corporativă cu multi-semnătură și ordine permanente blocate la înălțimea blocului.
  • Mecanismul de împrumut cu colateral. Împrumutătorii au blocat tokenuri EXTC într-un escrow al contractului; contractul a eliberat atomic veniturile împrumutului la primirea colateralului, fără întârziere de subscriere sau aprobare de comitet de credit.
  • Ce a relevat experimentul despre limitele Ethereum. La un debit mainnet de ~15 TPS și costuri de gaz de $0,10–$1,00 pe tranzacție la vârful din ianuarie 2018, o rețea de plată care procesează chiar și volume la scară de remitanțe era infezabilă economic și tehnic pe Ethereum public fără infrastructură Layer-2.

Problema de design: de ce ERC-20 era insuficient #

Standardul ERC-20, propus în 2015 și formalizat în Ethereum Improvement Proposal 20, a definit interfața canonică de token fungibil care a alimentat boom-ul ICO din 2017–2018. Cele șase funcții de bază — totalSupply, balanceOf, transfer, transferFrom, approve și allowance — erau suficiente pentru emisiunea și schimbul simplu de tokenuri.

Pentru o platformă de plată, totuși, ERC-20 avea un defect critic de producție. Funcția transfer(address _to, uint256 _value) muta tokenurile la orice adresă, inclusiv adrese de contracte, fără a declanșa niciun cod în contractul destinatar. Un contract care nu era programat specific să urmărească transferurile ERC-20 primite nu avea nicio modalitate de a le detecta. Tokenurile trimise astfel erau blocate permanent, fără niciun mecanism de recuperare.

Comunitatea Ethereum estima că zeci de milioane de dolari în tokenuri ERC-20 fuseseră pierdute permanent până la mijlocul anului 2018 prin acest mecanism. Construirea unei platforme de plată în care transferurile puteau eșua silențios și distruge fondurile utilizatorilor nu era acceptabilă.

Soluția ERC-223: transfer atomic cu notificare #

ERC-223, propus pe tracker-ul de probleme GitHub Ethereum EIPs, a abordat problema pierderii silențioase schimbând cerințele unui transfer de token. Sub ERC-223, transfer(address _to, uint256 _value, bytes _data) verifica dacă adresa destinatară conținea cod de contract. Dacă da, transferul apela _to.tokenFallback(address _from, uint256 _value, bytes _data).

Proprietatea critică: dacă contractul destinatar nu implementa tokenFallback, întreaga tranzacție de transfer se anula. Niciun token nu părăsea balanța expeditorului. Niciun token nu era blocat. Transferul era atomic — fie se finaliza cu executarea codului destinatarului, fie eșua complet cu starea neschimbată.

Pentru EXTC, aceasta înseamnă:

Arhitectura contractului EXTC #

Contractul de token EXTC era o implementare Solidity structurată în jurul a cinci module:

1. Identitatea tokenului #

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

Optsprezece zecimale au oferit EXTC o precizie sub un cent, corespunzând granularității necesare pentru cazurile de utilizare de micro-plată și micro-împrumut. Simbolul EXTC era identificatorul on-chain înregistrat în contractul de token.

2. Ofertă totală fixă #

Oferta totală a fost stabilită la implementarea contractului și nu putea fi mărită prin emitere ulterioară. Această alegere de design a făcut EXTC deflaționar: orice tokenuri eliminate permanent din circulație — prin operații de ardere ireversibilă — au redus oferta fără înlocuire. Modelul de ofertă fixă era standard în designurile de tokenuri de plată din 2018, reflectând ipoteza influențată de Bitcoin că presiunea deflationistă era o caracteristică pentru un mijloc de schimb.

3. Balanță și transfer conform ERC-223 #

Funcția de transfer de bază a implementat interfața completă ERC-223. Mapările interne de balanță urmăreau deținerile fiecărei adrese. Ajutorul isContract(address) distingea adresele EOA (cont deținut extern) de adresele contractelor pentru a determina dacă tokenFallback trebuia apelat.

4. Disbursări corporative cu multi-semnătură #

Fluxurile de plată corporative necesitau co-autorizare: niciun semnatar nu putea unilateral iniția o disbursare peste un prag definit. Contractul EXTC a implementat o schemă de multi-semnătură doi din N:

  1. Un inițiator desemnat propunea un transfer, specificând destinatarul, suma și un nonce.
  2. Un co-semnatar confirma nonce-ul.
  3. Doar după ce ambele semnături erau înregistrate on-chain se executa transferul.

Aceasta a eliminat riscul unui singur punct de eșec pentru conturile corporative, menținând în același timp întregul flux de autorizare on-chain și auditabil fără intermediarul unei case de compensare.

5. Ordine permanente blocate la înălțimea blocului #

Plățile recurente — salarii, abonamente, rambursări programate de împrumuturi — necesitau o primitivă de ordin permanent. EXTC a implementat aceasta ca un time-lock: o înregistrare de transfer era stocată în contract cu un parametru releaseBlock. Transferul nu putea fi executat până când înălțimea blocului Ethereum nu atingea releaseBlock.

Înălțimea blocului ca proxy temporal era o alegere pragmatică în 2018. Ethereum viza un interval de bloc de 15 secunde, făcând înălțimea blocului un proxy rezonabil de fiabil pentru ora reală în câteva minute. Marcajele de timp absolute (block.timestamp) erau disponibile, dar susceptibile la manipulare de către mineri în fereastra de ±900 de secunde, făcând înălțimea blocului referința mai sigură pentru contractele financiare.

Mecanismul de împrumut instant garantat cu colateral #

Primitiva de creditare EXTC era componenta cea mai complexă. Designul:

  1. Împrumutatul blochează colateralul. Împrumutatul apela lockCollateral(uint256 _collateralAmount), transferând tokenuri EXTC în escrow-ul contractului de creditare prin ERC-223 tokenFallback.
  2. Verificarea raportului împrumut-valoare. Contractul citea un raport LTV pre-configurat (de ex. 50%) și calcula suma maximă a împrumutului față de colateralul blocat.
  3. Disbursarea atomică a împrumutului. Dacă colateralul îndeplinea pragul minim, contractul transfera imediat suma împrumutului la adresa împrumutatului. Fără coadă de subscriere, fără comitet de credit, fără întârziere de decontare.
  4. Rambursare și eliberare. La rambursare — principal plus o rată fixă a dobânzii — contractul elibera colateralul înapoi împrumutatului. Nerespectarea rambursării înainte de releaseBlock declanșa lichidarea automată: contractul transfera colateralul la adresa desemnată a creditorului.

Întregul flux era aplicat de codul contractului. Niciuna dintre părți nu trebuia să aibă încredere în cealaltă sau să se bazeze pe un intermediar pentru a aplica termenii.

Ce a revelat experimentul #

Arhitectura contractului EXTC era coerentă din punct de vedere tehnic. ERC-223 a rezolvat cel mai serios defect de siguranță al ERC-20. Primitivele multi-semnătură și time-lock se mapau direct la fluxurile reale de plată corporativă. Mecanismul de împrumut cu colateral a demonstrat că creditarea garantată putea fi pe deplin automatizată și auto-aplicabilă on-chain.

Două constrângeri s-au revelat în practică:

Costurile de gaz. La vârful din ianuarie 2018, prețurile gazului Ethereum au atins 50–100 gwei, făcând un singur transfer de token ERC-223 să coste $0,50–$2,00. Pentru micro-plăți sau remitanțe de $10–$50, aceste taxe erau prohibitive.

Debitul. Limita de gaz a blocului mainnet Ethereum la începutul anului 2018 era de aproximativ 8 milioane de gaz. Un transfer ERC-223 consuma aproximativ 50.000–80.000 de gaz. Rețeaua putea procesa astfel aproximativ 100–160 de transferuri de tokenuri EXTC pe bloc, sau aproximativ 7–11 pe secundă la intervalul de bloc de 15 secunde. Scala rețelei de plată — sute sau mii de tranzacții pe secundă — nu era realizabilă pe Ethereum public fără infrastructura Layer-2 care nu exista încă în formă de producție.

Acestea erau constrângeri de infrastructură, nu defecte de design în EXTC. Logica contractului era corectă. Blockchain-ul subiacent nu putea încă susține volumul de plată la scara industriei financiare.

Ideile care au ajuns în producție #

Mai multe tipare de design din EXTC au fost validate de dezvoltarea ulterioară:

Transferul atomic de token cu notificarea destinatarului — proprietatea de bază ERC-223 — a devenit baza pentru ERC-777 (2019), care a extins modelul de notificare și a fost ulterior incorporat în protocoalele de creditare DeFi. Tiparul tokenFallback apare în toată arhitectura modernă DeFi.

Autorizarea multi-semnătură pentru disbursările corporative — tiparul de a necesita mai multe semnături on-chain înainte de execuție — a devenit modelul standard pentru managementul trezoreriei DAO și soluțiile de custodie instituțională. Gnosis Safe, lansat în 2018, a popularizat acest tipar la scară.

Împrumuturi instant garantate cu colateral fără intermediari — mecanismul de blocare a colateralului în escrow și eliberarea atomică a veniturilor împrumutului — este designul fundamental al protocoalelor de creditare DeFi precum Compound (2018) și Aave (2020).

Blocări temporale la înălțimea blocului pentru plăți programate — tiparul de codificare a timpului de execuție viitor în contract — apare în contractele de vesting de tokenuri, propunerile de guvernanță amânate și designurile oracolelor de preț mediu ponderat în timp (TWAP) din ecosistemul DeFi.

Experimentul EXTC nu a ajuns la scară de producție. Infrastructura necesară pentru a face designul viabil a necesitat încă trei până la cinci ani pentru a se matura. Întrebările de design pe care le-a pus erau cele corecte pentru 2018.

Întrebări frecvente #

De ce ERC-223 nu a fost niciodată adoptat ca standard dominant de token, în ciuda corectării defectului ERC-20?

ERC-223 impunea contractelor destinatare să implementeze tokenFallback, rupând compatibilitatea cu miile de contracte deja implementate pentru tokenuri ERC-20. Ecosistemul ERC-20 existent era prea mare pentru migrare. Propunerile ulterioare — în special ERC-777 și ERC-1363 — au abordat aceeași problemă cu compromisuri diferite de compatibilitate, dar ERC-20 a rămas dominant printr-o combinație de efecte de rețea și introducerea tiparelor de tokenuri ambalate care evitau scenariul pierderii silențioase.

Ce s-a întâmplat cu tokenul și platforma EXTC?

EXTC era o dovadă de concept și un proiect de cercetare timpurie din 2018. Piața mai largă ICO și a tokenurilor de plată s-a contractat brusc în 2018–2019, pe măsură ce limitele de scalabilitate Ethereum și incertitudinea de reglementare au devenit clare. Ideile încorporate în designul EXTC au reapărut în protocoale ulterioare care aveau acces la infrastructura Layer-2, instrumente mai bune și cadre de reglementare mai clare.

Cum se compară modelul de împrumut cu colateral al EXTC cu protocoalele DeFi moderne precum Aave?

Mecanismul de bază este același: blochează colateralul, primește un împrumut dimensionat față de un raport LTV, rambursează sau face față lichidării. Diferențele sunt: (1) protocoalele DeFi moderne folosesc fluxuri de prețuri oracle pentru LTV dinamic în loc de rapoarte fixe; (2) folosesc rate ale dobânzii algoritmice care răspund la utilizarea pool-ului; (3) operează pe rețele Layer-2 cu costuri de gaz de 10–100 de ori mai mici decât mainnet-ul din 2018; (4) Aave și Compound au trecut prin audituri formale de securitate și au deținut miliarde de dolari în lichiditate, oferind validare empirică că modelul de bază este solid.

Care erau constrângerile versiunii Solidity la începutul anului 2018?

Contractul EXTC a fost scris pentru Solidity 0.4.x, versiunea dominantă la începutul anului 2018. Solidity 0.4 lipsea multe funcții de siguranță introduse în versiunile ulterioare: verificarea depășirii întregilor (adăugată automat în 0.8.0), require/revert cu mesaje de eroare (limitat în 0.4) și vizibilitate explicită a funcțiilor (implicit public în 0.4). Contractul s-a bazat pe biblioteca SafeMath de la OpenZeppelin pentru a proteja împotriva depășirii, un tipar comun înainte ca compilatorul să aplice acest lucru nativ.

Referințe #

Ultima revizuire .

Ultima revizuire .