A ZK-tech alapú második rétegbeli megoldások a Human Rights Foundation ZK-Rollup Research Fellowship munkatársával John Lighttal együtt megjelenhetnek a bitcoinban, olyan javaslatot terjesztve elő, amely felkeltette néhány bitcoinfejlesztő figyelmét.
Az érvényességi összegzések és a bitcoin nagyon korlátozott szkriptnyelvén való megvalósításának hosszas áttekintésében a Light először hasznosan összefoglalja, mik ezek a még nagyon új találmányok:
„A rollup olyan blokklánc, amely tárolja az állapotgyökeret és legalább annyi tranzakciós adatot, amely az aktuális állapotot egy másik „szülő” blokklánc blokkján belüli genezisből kiszámolja, miközben a tranzakció végrehajtását a „láncon kívül” egy külön csomóponti hálózatra helyezi át.”
Az érvényességi összesítők elegendő adatot tartalmaznak a láncon az „érvényességi igazolásokhoz”, hogy biztosítsák, hogy az új összesítő blokkok megfeleljenek az összesítő protokoll szabályainak.
Ezek a bizonyítások a ZK-tech segítségével készülnek, manapság többnyire STARK-ok, és így gyakorlatilag egy tömörítési módszert kapunk, ahol mondjuk 100-szoros tranzakciót hajthatunk végre ezen a második rétegen, az alapréteg biztonságának túlnyomó többségével, és mindez csak annyit jelent. egy láncon belüli tranzakció.
Ennek jelentős előnye van a használhatóság terén, mint például a Lightning Network, mivel nincs szüksége olyan dolgokra, mint a biztosítékok, útválasztók stb., csak letétbe kell helyeznie az összegzőt.
Az egyszerű átvitelek érdekében nagyrészt az ethereumon valósították meg, ahol most egy teljes zk alapú Ethereum Virtual Machines-en dolgoznak, abban a reményben, hogy végül a ZK megoldást magára az alaprétegre is alkalmazni fogják.
A bitcoin terén azonban nem sok munka volt rajta egészen idén tavaszig, amikor Trey Del Bonis, a bitcoin fejlesztő közzétett kódpéldák arra vonatkozóan, hogyan lehet érvényességi összegzést megvalósítani a bitcoinban. Könnyű azt mondja,:
„Lehetséges lenne egy érvényességi összesítést építeni a bitcoinra a bitcoin natív Turing-inkomplett programozási nyelvével, a Scripttel, viszonylag kis változtatásokkal (a kód lábnyomát tekintve) a Script által támogatott műveleti kódokon…
Del Bonis szerint a bitcoin érvényességi összesítésének támogatásához szükséges változtatások néhány extra műveleti kód, amelyek lehetővé teszik összesítésének két fő primitívét – az érvényesség igazolást és a rekurzív szövetségeket…
A rekurzív szövetségek az intelligens szerződések egy fajtája, amely korlátozza a szkript típusát, amelyre a BTC elküldhető, miután elköltik.
A Del Bonis rekurzív egyezményeket használ az összesítő konstrukció minden állapotfrissítéssel történő terjesztésére, biztosítva, hogy az összesítő szkriptben zárolt, és a tulajdonos által még nem visszavont BTC-k továbbra is a szkriptben maradjanak az összesítő állapotfrissítésről a másikra.
Miután a BTC tulajdonosa az összesítésben megerősíti az érvényes visszavonási tranzakciót az összesítőn, akkor BTC-jével kiléphet a rekurzív szerződési szkriptből az általa megadott L1 kivonási címre.
A rekurzív szövetségek a Script megváltoztatása, amelyet a bitcoin közösség régóta fontolgat. Jelenleg azonban nincsenek konkrét javaslatok, amelyek széleskörű konszenzust értek volna el a bitcoin fejlesztői közösségben a rekurzív szövetségek bevezetésére vonatkozóan.
Elvileg ez egyszerűen hangzik. A rekurzív szerződések a zárolási résszel, vagy a pénzösszeg be- és kiszállításával foglalkoznak, míg néhány egyéb változtatás szükséges a bizonylatok integrálásához.
A bitcoin azonban köztudottan lassan változik, de Light szerint a javaslat teljes mértékben kompatibilis a bitcoin szellemiségével, és a bitcoin fejlesztői levelezőlistán is elmondja:
„Az érvényességi összegzések javíthatják a bitcoin méretezhetőségét, adatvédelmét és programozhatóságát anélkül, hogy feláldoznák a bitcoin alapvető értékeit vagy funkcionalitását, mint egyenrangú elektronikus készpénzrendszer.
Tekintettel az érvényességi összesítések „megbízhatatlan” jellegére, mint a szülőlánc kriptográfiailag biztonságos kiterjesztésére, és tekintettel a bitcoinnak a legbiztonságosabb elszámolási rétegként való státuszára, akár azt is mondhatnánk, hogy ezek a protokollok _tökéletesen illeszkednek_ egymáshoz.
Nem igényelnek extra sávszélességet vagy tárhelyet, így skálázhatóságot biztosítanak jelentős kompromisszumok nélkül.
A bitcoinban való megvalósításuk azonban valószínűleg nagyon lassú lesz, a Light helyett:
„Az Elements sidechain projekt (és az Elements alapú Liquid blokklánc) még nem támogatja az érvényességi igazolásokat, amelyek szükségesek az érvényességi összesítés támogatásához, de támogatja a rekurzív szövetségeket.
Az érvényességi igazolások támogatásának megvalósítása az Elementsben, valamint néhány más, Del Bonis által jónak tartott változtatással együtt út lehet egy olyan érvényességi összesítő protokoll teszteléséhez, amelyet végső soron bitcoinra szánnak.
A Liquid-et a Blockstream tartja karban, Greg Sanders pedig a Blockstream-től, aki a levelezőlista vitájában kijelenti:
„Létezik egy egyoldalas csalólap, amely „kéri” a tranzakciós introspekciót/OP_ZKP(?) és ezek használatát külön-külön és együtt is a különböző összesítő architektúrákhoz?”
Az Op_ZKP nem egészen létezik, talán ezért tette fel a kérdőjelet, de a kérdés arra utalhat, hogy bár elvileg könnyen hangzik, ennek megvalósítása a nagyon korlátozott bitcoin szkriptnyelven valószínűleg egyáltalán nem lesz egyszerű.
Nem utolsósorban azért, mert ez vérző élfejlesztés lenne, bár nem teljesen eredeti, mivel az ethereum fejlesztői 2019 óta dolgoznak ezeken a zk-rendszereken.
A szállítás mostanra elérte azt a pontot, ahol a csontvázat kirakták a bitcoin számára. A teljes megvalósítás azonban még sokáig tarthat.
Forrás: https://www.trustnodes.com/2022/10/12/validity-rollups-proposed-for-bitcoin