Sebastien Rousseau
Makipag-ugnayan ›

The making of the Express Transaction Credits Platform

Arkitektura ng token, multi-signature disbursements, at time-locked transfers sa Ethereum noong 2018.

11 min basahin
Banner for: The making of the Express Transaction Credits Platform

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

Buod ng Ehekutibo / Mga Pangunahing Aral

  • Ang ugat na problema. Ang ERC-20, ang nangunguna na pamantayan ng Ethereum token noong 2018, ay may istrukturang depekto: ang mga token na direktang inilipat sa address ng smart contract ay tahimik na nawasak kung walang handler ang kontrata. Anumang plataporma ng pagbabayad na itinayo sa ERC-20 ay nagmana ng panganib na iyon (Ethereum EIPs).
  • ERC-223 bilang solusyon. Hiniling ng ERC-223 sa mga kontrata ng tatanggap na ipatupad ang isang function na tokenFallback(address, uint, bytes). Kung wala, ang paglipat ay nababaligtad nang atomic. Walang token ang maaaring tahimik na mawala (Ethereum EIPs GitHub).
  • Ang limang primitibo ng kontrata ng EXTC. Pagkakakilanlan ng token (pangalan, simbolo, 18-decimal na katumpakan), nakapirming supply, ERC-223-compliant na paglipat, multi-signature na corporate disbursement, at mga standing order na time-locked batay sa taas ng bloke.
  • Ang mekanismo ng collateral loan. Nag-lock ng mga token ng EXTC ang mga nanghihiram sa isang contract escrow; inilabas ng kontrata ang mga kita ng pautang nang atomic sa pagtanggap ng collateral, nang walang pagkaantala ng underwriting o pag-apruba ng credit committee.
  • Kung ano ang inihayag ng eksperimento tungkol sa mga limitasyon ng Ethereum. Sa mainnet throughput na ~15 TPS at gastos ng gas na $0.10–$1.00 bawat transaksyon sa pinakamataas ng Enero 2018, ang isang network ng pagbabayad na nagpoproseso ng kahit na dami ng remittance ay hindi ekonomiko at teknikal na posible sa pampublikong Ethereum nang walang Layer-2 na imprastraktura.

Ang Problema sa Disenyo: Bakit Hindi Sapat ang ERC-20 #

Ang pamantayan ng ERC-20, na iminungkahi noong 2015 at pormal na naitatag sa Ethereum Improvement Proposal 20, ay nagtatag ng canonical fungible token interface na nagpalakas sa ICO boom ng 2017–2018. Ang anim na pangunahing function nito — totalSupply, balanceOf, transfer, transferFrom, approve, at allowance — ay sapat para sa simpleng pag-isyu ng token at palitan.

Para sa isang plataporma ng pagbabayad, gayunpaman, ang ERC-20 ay may kritikal na depekto sa produksyon. Ang function na transfer(address _to, uint256 _value) ay naglipat ng mga token sa anumang address, kabilang ang mga address ng kontrata, nang hindi nagpapalitaw ng anumang code sa tumatanggap na kontrata. Ang isang kontrata na hindi partikular na na-program upang subaybayan ang mga papasok na paglipat ng ERC-20 ay walang paraan upang matukoy ang mga ito. Ang mga token na ipinadala sa ganitong paraan ay permanenteng nabibigkis, nang walang mekanismo para sa pagbawi.

Tinantya ng komunidad ng Ethereum na sampung milyun-milyong dolyar na mga token ng ERC-20 ang permanenteng nawala sa kalagitnaan ng 2018 sa pamamagitan ng mekanismong ito. Ang pagtatayo ng isang plataporma ng pagbabayad kung saan ang mga paglipat ay maaaring tahimik na mabigo at masira ang mga pondo ng gumagamit ay hindi katanggap-tanggap.

Ang Solusyon ng ERC-223: Atomic Transfer na may Abiso #

Ang ERC-223, na iminungkahi sa Ethereum EIPs GitHub issue tracker, ay natugunan ang problema ng tahimik na pagkawala sa pamamagitan ng pagbabago ng kung ano ang kinakailangan ng isang paglipat ng token na gawin. Sa ilalim ng ERC-223, ang transfer(address _to, uint256 _value, bytes _data) ay sinuri kung ang tatanggap na address ay naglalaman ng code ng kontrata. Kung gayon, ang paglipat ay tumawag ng _to.tokenFallback(address _from, uint256 _value, bytes _data).

Ang kritikal na katangian: kung ang tatanggap na kontrata ay hindi nagpatupad ng tokenFallback, ang buong transaksyon ng paglipat ay nababaligtad. Walang token ang umalis sa balanse ng nagpadala. Walang token ang nabibigkis. Ang paglipat ay atomic — ito ay natapos na may code ng tatanggap na isinasagawa, o ganap na nabigo nang hindi nagbabago ang estado.

Para sa EXTC, nangangahulugan ito:

Ang Arkitektura ng Kontrata ng EXTC #

Ang kontrata ng token ng EXTC ay isang implementasyon ng Solidity na nakabalangkas sa paligid ng limang module:

1. Pagkakakilanlan ng Token #

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

Labinwalong decimal na lugar ang nagbigay sa EXTC ng sub-cent na katumpakan, na tumutugma sa granularity na kinakailangan para sa mga kaso ng paggamit ng micro-payment at micro-loan. Ang simbolo na EXTC ay ang on-chain na identifier na nairehistro sa kontrata ng token.

2. Nakapirming Kabuuang Supply #

Ang kabuuang supply ay itinakda sa deployment ng kontrata at hindi maaaring palakihin ng mga kasunod na mint. Ang pagpipilian sa disenyong ito ay ginawang deflationary ang EXTC: ang anumang token na permanenteng inalis mula sa sirkulasyon — sa pamamagitan ng mga hindi maibabalik na operasyon ng burn — ay nagpababa ng supply nang walang kapalit. Ang modelo ng nakapirming supply ay pamantayan sa mga disenyo ng token ng pagbabayad noong 2018, na sumasalamin sa ipinapalagay na impluwensya ng Bitcoin na ang deflationary pressure ay isang tampok para sa isang midyum ng palitan.

3. ERC-223 na Katugmang Balanse at Paglipat #

Ang pangunahing function ng paglipat ay nagpatupad ng buong interface ng ERC-223. Ang mga panloob na mapa ng balanse ay sinubaybayan ang mga hawak ng bawat address. Ang helper na isContract(address) ay nagpapakilala ng mga EOA (externally owned account) na address mula sa mga address ng kontrata upang matukoy kung kailangan bang tawagan ang tokenFallback.

4. Multi-Signature na Corporate Disbursement #

Ang mga workflow ng pagbabayad ng korporasyon ay nangangailangan ng co-authorisation: walang iisang pumirma ang maaaring unilaterally na simulan ang isang disbursement na higit sa isang tinukoy na threshold. Ang kontrata ng EXTC ay nagpatupad ng dalawang-sa-N na multi-signature scheme:

  1. Isang itinalagang initiator ang nagmungkahi ng paglipat, na tinutukoy ang tatanggap, halaga, at isang nonce.
  2. Isang co-signer ang nagkumpirma ng nonce.
  3. Pagkatapos lamang na maitatala ang parehong lagda sa on-chain ay isinagawa ang paglipat.

Inalis nito ang panganib ng single-point-of-failure para sa mga corporate account habang pinapanatili ang buong daloy ng pahintulot sa on-chain at naa-audit nang walang clearing house intermediary.

5. Block-Height na Time-Locked Standing Order #

Ang mga paulit-ulit na pagbabayad — mga sahod, subscription, nakatakdang pagbabayad ng utang — ay nangangailangan ng isang standing-order primitive. Isinagawa ng EXTC ito bilang isang time-lock: isang tala ng paglipat ang nakaimbak sa kontrata na may parameter na releaseBlock. Hindi maaaring maisakatuparan ang paglipat hanggang ang taas ng bloke ng Ethereum ay maabot ang releaseBlock.

Ang taas ng bloke bilang isang proxy ng oras ay isang pragmatikong pagpipilian noong 2018. Naka-target ang Ethereum ng 15-segundo na agwat ng bloke, na ginagawang isang medyo maaasahang proxy ang taas ng bloke para sa oras ng relo sa loob ng ilang minuto. Ang mga ganap na timestamp (block.timestamp) ay available ngunit madaling mamanipula ng mga miner sa loob ng isang ±900-segundo na window, na ginagawang mas ligtas na sanggunian ang taas ng bloke para sa mga kontratang pinansyal.

Ang Mekanismo ng Instant na Pautang na Siniguradong may Collateral #

Ang EXTC lending primitive ay ang pinaka-kumplikadong bahagi. Ang disenyo:

  1. Nag-lock ng collateral ang nanghihiram. Tinawag ng nanghihiram ang lockCollateral(uint256 _collateralAmount), na naglilipat ng mga token ng EXTC sa lending contract escrow sa pamamagitan ng ERC-223 tokenFallback.
  2. Pagsusuri ng loan-to-value ratio. Binasa ng kontrata ang isang pre-configured na LTV ratio (hal. 50%) at kinakalkula ang pinakamataas na halaga ng pautang laban sa naka-lock na collateral.
  3. Atomic na loan disbursement. Kung natugunan ng collateral ang minimum na threshold, agad na inilipat ng kontrata ang halaga ng pautang sa address ng nanghihiram. Walang underwriting queue, walang credit committee, walang pagkaantala ng settlement.
  4. Pagbabayad at pagpapalaya. Sa pagbabayad — punong-utang kasama ang isang nakapirming rate ng interes — inilabas ng kontrata ang collateral pabalik sa nanghihiram. Ang kabiguan na bayaran ng releaseBlock ay nag-trigger ng awtomatikong liquidasyon: inilipat ng kontrata ang collateral sa itinalagang address ng nagpapautang.

Ang buong daloy ay isinagawa ng code ng kontrata. Hindi kailangan ng alinmang partido na magtiwala sa isa pang partido o umasa sa isang intermediary upang ipatupad ang mga tuntunin.

Kung Ano ang Inihayag ng Eksperimento #

Ang arkitektura ng kontrata ng EXTC ay teknikal na magkakaugnay. Nalutas ng ERC-223 ang pinaka-seryosong depekto sa kaligtasan ng ERC-20. Ang mga primitibo ng multi-signature at time-lock ay direktang nakamapa sa mga tunay na workflow ng pagbabayad ng korporasyon. Ipinakita ng mekanismo ng collateral loan na ang secured na pagpapautang ay maaaring ganap na awtomatiko at self-enforcing sa on-chain.

Dalawang limitasyon ang nabunyag sa pagsasanay:

Mga gastos ng gas. Sa pinakamataas ng Enero 2018, ang mga presyo ng gas ng Ethereum ay umabot sa 50–100 gwei, na ginagawang ang isang paglipat ng token ng ERC-223 ay nagkakahalaga ng $0.50–$2.00. Para sa mga micro-payment o remittance na $10–$50, ang mga bayad na iyon ay napakalaki.

Throughput. Ang Ethereum mainnet block gas limit sa unang bahagi ng 2018 ay halos 8 milyong gas. Ang isang paglipat ng ERC-223 ay gumamit ng halos 50,000–80,000 gas. Kaya naman ang network ay maaaring magproseso ng halos 100–160 na paglipat ng token ng EXTC bawat bloke, o halos 7–11 bawat segundo sa 15-segundo na agwat ng bloke. Ang sukat ng network ng pagbabayad — daan-daan o libu-libong transaksyon bawat segundo — ay hindi makamit sa pampublikong Ethereum nang walang Layer-2 na imprastraktura na hindi pa umiiral sa anyo ng produksyon.

Ang mga ito ay mga limitasyon ng imprastraktura, hindi mga depekto sa disenyo sa EXTC. Ang lohika ng kontrata ay tama. Hindi pa kayang suportahan ng pinagbabatayan na blockchain ang dami ng pagbabayad sa sukat ng industriya ng pananalapi.

Ang mga Ideyang Umabot sa Produksyon #

Ilang pattern ng disenyo mula sa EXTC ang napatunayan ng kasunod na pag-unlad:

Ang atomic token transfer na may abiso ng tatanggap — ang pangunahing katangian ng ERC-223 — ay naging batayan ng ERC-777 (2019), na nagpalawak ng modelo ng abiso at kalaunan ay isinama sa mga DeFi lending protocol. Ang pattern na tokenFallback ay lumalabas sa buong modernong arkitektura ng DeFi.

Ang multi-signature na pahintulot para sa mga corporate disbursement — ang pattern ng pag-aatas ng maraming on-chain na lagda bago ang pagpapatupad — ay naging pamantayang modelo para sa pamamahala ng kayamanan ng DAO at mga solusyon sa institutional custody. Ang Gnosis Safe, na inilunsad noong 2018, ay nagsikat ng pattern na ito sa malaking sukat.

Ang mga instant na pautang na siniguradong may collateral nang walang intermediaries — ang mekanismo ng pag-lock ng collateral sa escrow at paglabas ng mga kita ng pautang nang atomic — ay ang pangunahing disenyo ng mga DeFi lending protocol tulad ng Compound (2018) at Aave (2020).

Ang mga time lock batay sa taas ng bloke para sa mga nakatakdang pagbabayad — ang pattern ng pag-encode ng timing ng pagsasagawa sa hinaharap sa kontrata — ay lumalabas sa mga token vesting contract, naantalang mga panukala sa pamamahala, at mga disenyo ng oracle ng time-weighted average price (TWAP) sa buong DeFi ecosystem.

Ang eksperimento ng EXTC ay hindi umabot sa sukat ng produksyon. Ang imprastrakturang kinakailangan upang gawing posible ang disenyo ay tumagal ng tatlo hanggang limang taon pa upang lumago. Ang mga tanong sa disenyo na itinataon nito ay ang tamang mga tanong para sa 2018.

Mga Madalas Itanong #

Bakit hindi kailanman pinagtibay ang ERC-223 bilang nangunguna na pamantayan ng token sa kabila ng pag-aayos ng depekto ng ERC-20?

Hiniling ng ERC-223 sa mga kontrata ng tatanggap na ipatupad ang tokenFallback, na sinasaklaw ang backwards compatibility sa libu-libong kontratang naka-deploy na para sa mga token ng ERC-20. Ang umiiral na ecosystem ng ERC-20 ay masyadong malaki para ma-migrate. Ang mga kasunod na panukala — partikular na ang ERC-777 at ERC-1363 — ay tinutugunan ang parehong problema sa iba't ibang trade-off ng compatibility, ngunit nanaig ang ERC-20 sa pamamagitan ng kumbinasyon ng mga epekto ng network at pagpapakilala ng mga pattern ng wrapped token na umiiwas sa senaryo ng tahimik na pagkawala.

Ano ang nangyari sa token at plataporma ng EXTC?

Ang EXTC ay isang proof-of-concept at maagang proyekto ng pananaliksik mula sa 2018. Ang mas malawak na merkado ng ICO at token ng pagbabayad ay mabilis na lumaki noong 2018–2019 habang naging malinaw ang mga limitasyon ng scalability ng Ethereum at kawalan ng katiyakan sa regulasyon. Ang mga ideyang nakalakip sa disenyo ng EXTC ay muling lumabas sa mga susunod na protocol na may access sa Layer-2 na imprastraktura, mas magandang tooling, at mas malinaw na mga balangkas ng regulasyon.

Paano inihambing ang modelo ng collateral loan ng EXTC sa mga modernong DeFi protocol tulad ng Aave?

Ang pangunahing mekanismo ay pareho: i-lock ang collateral, makatanggap ng pautang na nasusukat laban sa isang LTV ratio, magbayad o harapin ang liquidasyon. Ang mga pagkakaiba ay: (1) gumagamit ang mga modernong DeFi protocol ng mga oracle price feed para sa dynamic na LTV kaysa sa mga nakapirming ratio; (2) gumagamit sila ng mga algorithmic na rate ng interes na tumutugon sa paggamit ng pool; (3) nag-ooperate sila sa mga Layer-2 na network na may mga gastos ng gas na 10–100 beses na mas mababa kaysa sa 2018 mainnet; (4) ang Aave at Compound ay dumaan sa mga pormal na security audit at nagpapanatili ng bilyun-bilyong dolyar sa liquidity, na nagbibigay ng empirical na pagpapatunay na ang pangunahing modelo ay makatuwiran.

Ano ang mga limitasyon ng bersyon ng Solidity sa unang bahagi ng 2018?

Ang kontrata ng EXTC ay isinulat para sa Solidity 0.4.x, ang nangunguna na bersyon sa unang bahagi ng 2018. Ang Solidity 0.4 ay kulang ng maraming tampok na kaligtasan na ipinakilala sa mga susunod na bersyon: integer overflow checking (awtomatikong naidagdag sa 0.8.0), require/revert na may mga mensahe ng error (limitado sa 0.4), at malinaw na visibility ng function (default ay public sa 0.4). Ang kontrata ay umasa sa SafeMath library ng OpenZeppelin upang protektahan laban sa overflow, isang karaniwang pattern bago ipatupad ng compiler ito nang natural.

Mga Sanggunian #

Huling sinuri .

Huling sinuri .