Pentru cei care ma urmaresc pe twitter, ati fi observat ca am postat cateva lucruri pe lanturi incrucisate, astazi am atins o etapa destul de mare a produsului pe care o vom lansa in urmatoarele saptamani, asa ca am vrut sa fac o pauza , si luati ceva timp pentru a explica ce este de fapt aceste lucruri.

Sa incepem cu BTC infasurat (wBTC). wBTC este BTC cu lant incrucisat. Depuneti BTC pe Bitcoin la un custode wBTC, odata ce custodele wBTC va primeste fondurile, acesta poate sa creasca wBTC si sa vi-l trimita.

Array

Atat de simplu. Trimiteti BTC pe Bitcoin la petrecerea A. Partidul A mentioneaza wBTC pe Ethereum. Aceasta poate fi considerata o solutie centralizata a custodelui, dar este inca incrucisata.

Array

Sa ne uitam la punctele cheie ale celor de mai sus;

  • BTC a fost transferat pe un portofel desemnat pe Bitcoin.
  • Partea A are un anumit mecanism de informare a tranzactiei anterioare si are un mecanism care sa confirme validitatea tranzactiei. In mod normal, aceasta implica interogarea unui nod complet Bitcoin.
  • Partidul A a batut wBTC pe Ethereum dupa confirmarea pasului 2.

    Array

Ce se intampla daca partidul A este compromis? Ar putea sa bata infinit wBTC pe Ethereum sau ar putea scurge toate BTC-urile depuse pe Bitcoin. Un pas urmator direct, il transforma intr-un portofel multisig si permite sa presupunem 5 participanti in total si cel putin 3 trebuie sa semneze pentru ca o tranzactie sa fie valida. Fluxul procesului este inca exact acelasi, trimiteti BTC pe Bitcoin la adresa multisig. Cand 3/5 participanti multisig sunt de acord cu primirea BTC, acestia bateau wBTC.

Cu designul de mai sus, adresa multisig devine in continuare un pot de miere, deoarece detine destul de mult BTC.

Pentru a intelege urmatorul bit, sa vedem rapid cum functioneaza AMM-urile precum Sushiswap. Intr-un AMM precum Sushiswap aveti 2 jetoane intr-o pereche, sa spunem ETH / BTC. Daca adaugati ETH, puteti retrage BTC si invers. De ce acest lucru nu creeaza acelasi pot de miere ca multisigul de mai sus? Deoarece proprietarul perechii nu are control asupra activelor.

Deci, cum putem folosi cele de mai sus pentru lanturi incrucisate? O pereche AMM este alcatuita din trei parti, simbolul A, simbolul B si un pret cotat bazat pe relatia dintre simbolul A si simbolul B. Deci, pentru ca un AMM sa fie valid, trebuie sa cunoasca cantitatea de simbol A si cantitatea a jetonului B. Aceasta inseamna totusi ca jetonul A si jetonul B nu trebuie neaparat sa traiasca pe acelasi lant.

Deci, un LP ar putea oferi lichiditate sub forma de ETH pe Ethereum si FTM pe Fantom. Perechea de pe Ethereum detine ETH si nu are FTM, dar este constienta de cat de mult FTM este detinut pe Fantom. Perechea de pe Fantom detine FTM si nu are ETH, dar este constienta de cat de mult se detine ETH pe Ethereum.

De unde stie perechea de pe Fantom, cat de mult ETH este pe Ethereum? In esenta, aceasta este o problema oracola. Acestea fiind spuse, orice oracol poate rezolva aceasta problema, fie ca sunt solutii oracole existente sau solutii noi. Afirmatia problemei aici este; cum stie lantul B ca a avut loc un eveniment pe lantul A. Intr-o lume ideala, lantul A si lantul B vorbesc acelasi „limbaj” sau protocol p2p, in timp ce cred ca acest lucru va deveni mai standardizat si vom vedea mai multe lanturi lightclients, deocamdata, acest lucru se realizeaza in mod normal prin intermediul unei retele terte.

Solutia actuala cea mai simplista este aceea de a avea mai multe noduri / servere / participanti care asculta toate evenimentele contractuale pe Ethereum / Fantom / BSC / etc. Cand o mare majoritate de noduri / servere / participanti sunt de acord ca au vazut evenimentul, pot declansa urmatorul eveniment din secventa. Lucrul cheie de remarcat aici este ca modul in care se ajunge la acest consens, nu conteaza prea mult pentru executia protocolului. Aceasta poate fi dovada autoritatii, dovada mizei, custodie, multisig etc. In esenta, aceasta este o problema de consens (care este un subset al problemei oracolului).

Punand totul impreuna;

Implementam un nou AMM cross-chain cross-asset pentru simbolul A pe lantul A si simbolul B pe lantul B, in scop ilustrativ, sa presupunem ETH pe Ethereum si FTM pe Fantom. Piscina este insamantata cu 100 ETH si 200.000 FTM. Oricine poate adauga lichiditate si oricine poate adauga lichiditate.

Alice vine si adauga 1 ETH la piscina si retrage 2.000 FTM virtual (vFTM). Sa presupunem ca reteaua noastra oracle ruleaza ~ 10 noduri, cu o cerinta consens 2n / 3. Fiecare dintre aceste noduri fie isi ruleaza propriile noduri complete, fie se aboneaza la API-urile infura / alchemy / pokt. Cand 7 (2n / 3) noduri stiu ca Alice a adaugat 1 ETH, creeaza un nou eveniment care actualizeaza AMM pe Fantom pentru a adauga 1 ETH virtual (vETH) si trimite 2000 FTM catre Alice.

Retineti ca cele de mai sus reprezinta o simplificare destul de mare a modului in care interactioneaza toate aceste componente, dar ar trebui sa ofere o indicatie decenta a modului in care arata un swap intre active de tip cross-chain. O parte importanta pe care am omis-o ca parte a acestui articol este garantiile economice pentru reteaua Oracle, de asemenea, ce au in joc acele 10 noduri, astfel incat, daca se comporta gresit, ar fi reduse. In designul de mai sus, ar putea „fura” toate cele 100 ETH si 200.000 FTM, prin coluziune intre ele pentru a scurge sistemul. Aceste garantii economice sunt esentiale pentru siguranta si siguranta unui sistem ca acesta, mai multe detalii despre acest lucru intr-un articol ulterior, avem ceva interesant care va iesi cu privire la acest lucru in viitor.

ARTICOLE SIMILAREDE LA ACELAȘI AUTOR