Immutable, dok ne nađeš bug
Deployani contract se ne krpa, pa se dodaje proxy i upgrade key. Taj ključ — a ne logika koju je audit provjerio — postaje ono što treba čuvati.
Immutability je prva stvar koju ti kažu o smart contractu, i točna je: kad je contract jednom deployan, njegov bytecode se više ne mijenja. Prodaje se kao jamstvo — nitko ne može pomaknuti pravila nakon činjenice, ni tim, ni osnivač, ni onaj tko će sutra kupiti tvrtku. Onda naiđe prvi pravi bug i jamstvo postane zamka. Ne popravljaš ono što ne možeš promijeniti. Rješenje koje se odmah poseže je poznato i sasvim razumno, ali poništava upravo svojstvo koje se prodavalo — i gotovo nijedna prezentacija to ne kaže naglas.
Proxy, i ključ koji uvodi
Standardno rješenje je proxy pattern. Contract se podijeli na dva. Proxy contract drži state i adresu s kojom svi komuniciraju, i prosljeđuje svaki poziv — preko delegatecall — zasebnom logic contractu koji sadrži kod. Kad trebaš popraviti bug, deployaš novu logiku, v2, i usmjeriš proxy na nju. Adresa kojoj korisnici vjeruju nikad se ne mijenja; mijenja se ponašanje iza nje.
Elegantno je i radi. Ali stvara nešto što trenutak prije nije postojalo: administrativni ključ koji odlučuje koju logiku proxy izvršava. Tko drži taj ključ može promijeniti što contract radi, nakon što su mu ljudi već počeli vjerovati. Točka povjerenja se tiho pomaknula. Prije je bila "bytecode se ne može promijeniti". Sada je "onaj tko drži upgrade key neće ga zloupotrijebiti".
Ključ je važniji od logike koju je audit provjerio
To je dio koji se izgubi. Platio si audit, i audit je provjerio logic contract: njegovu aritmetiku, provjere pristupa, rukovanje rubnim slučajevima. Ali adresa koja može zamijeniti tu logiku stoji izvan jamstva audita. Čist izvještaj o v1 ne govori ništa o tome tko može ubaciti v3 u dva ujutro.
Ako je taj upgrade key jedan wallet — jedan private key na jednom laptopu — onda je "immutable i trustless" tekst iz brošure. Rekonstruirao si database administratora s write pristupom produkciji, samo uz nekoliko koraka više i račun za gas. Napadač koji ukrade taj ključ ne treba reentrancy bug: uopće ne napada logiku, samo je nadogradi. Sigurnosni model mora uključivati ključ, ne samo kod.
Za tvrtke u regiji pitanje je kome vjeruješ
Za tvrtke u regiji i strane partnere ovo pomiče due diligence, ne samo arhitekturu. Pitanje nije je li contract auditiran, nego tko drži ključ i što ga zaustavlja. Ista logika kao kod svakog kritičnog sustava: tko ima write pristup produkciji, i koja ga kontrola koči.
Tri mehanizma odrade najveći dio posla. Multisig, da upgrade traži više nezavisnih potpisa umjesto ključa jedne osobe. Timelock, da promjena u redu ostane vidljiva on-chain neko fiksno vrijeme prije nego se aktivira — dovoljno da onaj tko gleda stigne reagirati. I jasno objašnjenje mehanizma, da partner zna čemu vjeruje prije nego uloži sredstva. Immutability koju ne možeš popraviti je rizik. Upgradeability koju nitko ne vidi da dolazi je gora.
Tko na vašem contractu može promijeniti ponašanje sutra — i bi li itko to primijetio na vrijeme?