Eszköz a metamorf intelligens szerződések észleléséhez

Az Ethereum egyik kritikus biztonsági feltételezése az, hogy az intelligens szerződés kódja megváltoztathatatlan, és ezért nem módosítható, miután telepítette a blokkláncra. A gyakorlatban néhány intelligens szerződés tud változás – még a telepítés után is. Néhány ügyes trükkel olyan metamorf intelligens szerződéseket hozhat létre, amelyek „metamorfózis” valami másba – és ha megérti, mi teszi lehetővé őket, akkor felismerheti őket.

A metamorf intelligens szerződések változtathatók, ami azt jelenti, hogy a fejlesztők megváltoztathatják a bennük lévő kódot. Ezek az intelligens szerződések komoly kockázatot jelentenek a web3-felhasználók számára, akik bíznak abban a kódban, amelytől elvárják, hogy teljes következetességgel futtasson, különösen mivel a rossz szereplők kihasználhatják ezt az alakváltó képességet. Képzeljünk el egy támadót, aki ezt a technikát használja, hogy „szőnyeget” használjon az embereknek, akik tokeneket helyeznek el egy intelligens szerződésben, amelyről nem veszik észre, hogy metamorf. Az ezen és hasonló feltételezéseken alapuló támadások arra késztethetik a csalókat, hogy embereket zsákmányoljanak, és általában aláássák a decentralizált rendszerek teljes ígéretébe vetett bizalmat.

Annak elemzéséhez, hogy egy intelligens szerződés tartalmaz-e metamorf tulajdonságokat, Egy egyszerűt építettem Metamorf szerződés detektor (az eredeti munkája ihlette és azokra építve Jason faragó, 0 korés mások). Bárki használhatja az eszközt annak ellenőrzésére, hogy az adott szerződésen szerepel-e piros zászló, amely utalhat a metamorfózis lehetőségére. A módszer nem bolondbiztos: attól, hogy egy intelligens szerződésen zászló látható, még nem feltétlenül metamorf; és attól, hogy nem, még nem biztos, hogy biztonságos. Az ellenőr csupán egy gyors kezdeti értékelést kínál a szerződésről esetleg a lehetséges indikátorok alapján legyen metamorf. 

A Web3 felhasználóknak meg kell ismerkedniük a metamorf szerződések jelentette fenyegetésekkel, hogy figyeljenek és elkerülhessék az esetleges támadásokat. A pénztárcák és a blokklánc-indexelők segíthetnek abban, hogy figyelmeztetik a felhasználókat, mielőtt olyan intelligens szerződést kötnének, amely metamorf tulajdonságokat tartalmazhat. Ennek az eszköznek az a célja, hogy segítsen az emberek felvilágosításában erről a lehetséges fenyegetésről… és az ellene való védekezésben.

Metamorf intelligens szerződések észlelése

A Metamorf szerződés detektor Hat olyan tulajdonság elemzését készítettem, amelyek jelezhetik, hogy egy intelligens szerződés metamorf-e.

1. 1. Használtak ismert metamorf kódot a szerződés telepítéséhez? Ha az ismert metamorf bájtkód – az az alacsonyabb szintű, virtuális géppel olvasható kód, amelyvé az Ethereum intelligens szerződései, jellemzően Solidityben írva, fordításuk után átalakulnak – megjelenik egy adott intelligens szerződés telepítésére vonatkozó tranzakcióban, az egy fontos piros zászló. A következő szakaszokban a 0age által kifejlesztett metamorf bájtkód egy ilyen példáját tárgyaljuk. Egy fontos figyelmeztetés: A metamorf bájtkódnak potenciálisan számtalan változata létezik, ami megnehezíti az összes fajta észlelését. Azáltal, hogy jól ismert példányokat keres, az érzékelő kiküszöböli az alacsonyan lógó gyümölcsöket a támadók számára, akik csupán meglévő példákat másolnak és illesztenek be.
   2. Az intelligens szerződés kódja képes önmagát megsemmisíteni? A szerződésben szereplő kód cseréjéhez – ami egy kulcsfontosságú lépés a metamorf szerződés létrehozásában – a fejlesztőnek először törölnie kell a már meglévő kódot. Ennek egyetlen módja a SELFDESSTRUCT műveleti kód, egy parancs, amely pontosan azt csinálja, aminek hangzik – törli az összes kódot és tárhelyet egy adott szerződési címen. Az önmegsemmisítő kód jelenléte egy szerződésben nem bizonyítja, hogy metamorf; azonban arra utal, hogy a szerződés esetleg legyen metamorf, és mindenesetre érdemes tudni, hogy a szerződések, amelyekre támaszkodik, elpusztíthatják-e magukat.
   3. Az intelligens szerződés máshonnan hívja be a kódot? Ha a kérdéses intelligens szerződés nem képes közvetlenül önmegsemmisíteni, akkor is képes lehet törölni magát a DELEGATECALL műveleti kód. Ez a műveleti kód lehetővé teszi, hogy egy intelligens szerződés dinamikusan betöltse és végrehajtsa a kódot, amely egy másik intelligens szerződésben található. Még ha az intelligens szerződés nem is tartalmazza a SELFDESTRUCT műveleti kódot, a DELEGATECALL segítségével betöltheti az önmegsemmisítő kódot valahonnan máshonnan. Bár a DELEGATECALL funkció nem jelzi közvetlenül, ha egy intelligens szerződés átalakul, ez egy lehetséges nyom – és egy esetleges biztonsági probléma –, amelyet érdemes megjegyezni. Figyelmeztetni kell, hogy ez a mutató számos hamis pozitív eredményt okozhat. 
   4. Más szerződés alkalmazta ezt a szerződést? Metamorf szerződések telepíthetők csak más intelligens szerződésekkel. Ennek az az oka, hogy a metamorf szerződéseket egy másik műveleti kód engedélyezi, amelyet csak más intelligens szerződések használhatnak, az úgynevezett CREATE2. (A CREATE2-ről – hogyan működik és miért számít – egy későbbi részben fogunk beszélni.) Ez a tulajdonság az egyik legkevésbé szembetűnő mutatója a lehetséges metamorfózisnak; ez szükséges, de nem elégséges előfeltétel. Ennek a tulajdonságnak a keresése valószínűleg sok hamis pozitív eredményt vet fel – de értékes információ, mivel gyanút kelthet, és okot adhat a szerződés további vizsgálatára, különösen, ha az intelligens szerződés tartalmazza a következő műveleti kódot.
   5. A telepítői szerződés tartalmazza a CREATE2 műveleti kódot? Mint fentebb említettük, a CREATE2-n keresztüli telepítés elengedhetetlen előfeltétele a metamorfózisnak. Ha egy telepítői szerződés tartalmazza a CREATE2 műveleti kódot, ez azt jelezheti, hogy a CREATE2-t használta a kérdéses szerződés üzembe helyezéséhez. Ha a telepítő valóban a CREATE2-t használta az említett szerződés üzembe helyezéséhez, bár ez nem jelenti azt, hogy a szerződés szükségszerűen átalakul, ez azt jelenti, hogy esetleg legyen metamorf, és bölcs dolog lehet óvatosan eljárni és tovább vizsgálni. Ismét ügyeljen a hamis pozitív eredményekre: LÉTREHOZÁS2 rengeteg van jogszerű felhasználások, beleértve a megerősítést is „Layer 2” méretezési megoldások és megkönnyíti az intelligens szerződéses pénztárcák létrehozását, amelyek javíthatják a web3-at felhasználói beléptetés és kulcs-helyreállítási lehetőségek.
   6. Változott a kód? Ez a legnyilvánvalóbb üzenet, de csak akkor jelenik meg, ha egy metamorf szerződés már átalakult. Ha az intelligens szerződés kódkivonata – egy egyedi, kriptográfiai azonosító – eltér attól, ami a szerződés kezdeti üzembe helyezésekor volt, akkor valószínűleg a kódot eltávolították, kicserélték vagy módosították. Ha a hash-ek már nem egyeznek, akkor valami megváltozott a kódban, és a szerződés átalakulhat. Ez a zászló a metamorfizmus legbiztosabb jelzője, de nem segít megjósolni vagy megelőzni a morfiumot, mivel csak azt ellenőrzi, hogy az már megtörtént-e.

A Metamorphic Contract Detector egyszerű parancssori eszközének elkészítése mellett néhány példa intelligens szerződést építettem, amelyek egy átverés metamorf szerződéses forgatókönyvet mutatnak be, amelyet a következő részben ismertetek. Ebben az összes kód elérhető GitHub tárház. 

Hogyan tud egy rosszindulatú szereplő metamorf szerződésekkel ellopni az emberek pénzét

Íme, hogyan használhat valaki egy átverés részeként egy metamorf intelligens szerződést. 

Az első a beállítási fázis. A támadó egy intelligens szerződést telepít egy adott címre a blokkláncon két eszköz segítségével: a metamorf bájtkóddal és a CREATE2 műveleti kóddal. (Később kibővítjük mindkét fogalmat.) A metamorf bájtkód ezután azt teszi, amit a neve sugall, és „morfizál”. Itt átváltozik a tét szerződés ahol a felhasználók ERC-20 tokeneket helyezhetnek el. (Ismét, ennek a morfondírozó trükknek a részleteiről később fogunk beszélni. Ígérd meg!)

Ezután jön a csali és a kapcsoló. A gyanútlan felhasználók tétbe helyezik zsetonjaikat ebben a szerződésben, a hozam vagy más jutalom megszerzésének lehetőségével csábítva. A támadó ezután törli az összes kockáztatott kódot és „állapotot” – blokklánc tárolót vagy memóriát – ezen az intelligens szerződés címén a SELFDESSTRUCT műveleti kód az előző részben tárgyaltuk. (Megjegyzendő, hogy a tokenek – amelyek egy külön ERC-20 szerződés részeként léteznek – megmaradnak, nem érinti őket az önmegsemmisítő szerződés.)

Végül a szőnyeghúzás. A támadó ugyanazt a metamorf bájtkódot használja, amelyet a telepítési fázisban használt egy új szerződés „újratelepítéséhez”. Ez az új szerződés ugyanarra a címre vonatkozik, amelyet nemrégiben elhagyott az önmegsemmisítő szerződés. Ezúttal azonban a bájtkód egy rosszindulatú szerződéssé „amorph” (újra később elmagyarázzuk, hogyan), amely képes ellopni a szerződés címén elhelyezett összes tokent. Átverés kész. 

A metamorf intelligens szerződések kockázatai mára nyilvánvalóak. De még mindig azon töprenghet, hogyan is működik ez a metamorfizmus trükk? Ennek megértéséhez mélyebbre kell vizsgálni, a bájtkód szintjéig. 

Hogyan nyitja meg a CREATE2 a metamorfizmus lehetőségét 

LÉTREHOZÁS2 egy opcode frissítés, bevezették az Ethereumba 2019 februárjában ez új módot kínál az intelligens szerződések bevezetésére. 

A CREATE2 a fejlesztők számára nagyobb ellenőrzést biztosít intelligens szerződéseik bevezetése felett, mint korábban. Az eredeti CREATE műveleti kód megnehezíti a fejlesztők számára a telepítendő intelligens szerződés célcímének szabályozását. A CREATE2 segítségével az emberek előre ellenőrizhetik és megtudhatják egy adott intelligens szerződés címét, mielőtt ténylegesen telepítenék a blokkláncra. Ez az előzetes tudás – plusz néhány okos trükk – képessé teszi az embereket metamorf intelligens szerződések létrehozására. 

Hogyan tudja a CREATE2 megjósolni a jövőt? Az opcode számítása determinisztikus: amíg a bemenetek nem változnak, addig a CREATE2 által meghatározott cím nem változik. (Még a legkisebb változtatás is azt eredményezi, hogy a telepítés valahol máshol történik.)

Pontosabban, a CREATE2 egy olyan függvény, amely egyesít és összevon néhány elemet. Először is tartalmazza a telepítő (vagy feladó) címét: a kezdeményező intelligens szerződést, amely a létrehozandó szerződés szülőjeként működik. Ezután hozzáad egy tetszőleges számot a feladótól (vagy „sót”), amely lehetővé teszi a fejlesztő számára, hogy ugyanazt a kódot különböző címekre telepítse (a só megváltoztatásával), és megakadályozza a meglévő, azonos szerződések felülírását. Végül az intelligens szerződés inicializálásának ("init") bájtkódjának keccak256 hash-jét használja, amely az a mag, amely új intelligens szerződéssé válik. Ez az összevont kombináció meghatároz egy Ethereum-címet, majd telepíti az adott bájtkódot erre a címre. Amíg a bájtkód pontosan ugyanaz marad, a CREATE2 mindig ugyanarra a címre telepíti a megadott bájtkódot a blokkláncon.

Így néz ki a CREATE2 képlet. (Megjegyzés: az alábbi példában egy másik elem, a „0xFF” is látható. Ez csak egy állandó CREATE2 ütközések megelőzése az előző CREATE műveleti kóddal.)

Most, hogy módunk van arra, hogy kódot telepítsünk egy determinisztikus címre, hogyan lehetséges változik a kód ugyanazon a címen? Elsőre ez lehetetlennek tűnhet. Ha új kódot szeretne telepíteni a CREATE2 használatával, a bájtkódnak meg kell változnia, ezért a CREATE2 egy másik címre fog telepíteni. De mi van akkor, ha a fejlesztő úgy állítja össze a bájtkódot, hogy az más kódokká alakuljon át, amikor a CREATE2 intelligens szerződést telepít?

Hogyan működik valójában egy metamorf szerződés

Az intelligens szerződés metamorf szerződéssé alakításának receptje összesen három intelligens szerződést igényel, amelyek mindegyike egyedi szerepet játszik.

Az egyik ilyen szükséges komponens a Metamorphic Contract Factory, a művelet agya. Ez a „Gyár” felelős a Metamorphic Contract, valamint egy másik intelligens szerződés, az Implementation Contract bevezetéséért, így azért nevezték el, mert a kódja végül a Metamorphic Contract-en belül kerül megvalósításra. A három kontraktus közötti finom koreográfia metamorfizmust eredményez, amint azt az alábbi ábra mutatja.

Beszéljünk részletesen minden lépésről, 1-7, hogy megvilágítsuk a munkavégzést.

1. lépés: A fejlesztő mindent mozgásba hoz

A kódoló megtervez néhány intelligens szerződéskódot – az implementációs szerződés bájtkódját –, amely végül a metamorf szerződésbe kerül. A fejlesztő elküldi ezt a kódot a Metamorphic Contract Factory-nak, egy intelligens szerződésnek, amelynek fő célja más intelligens szerződések telepítése. Ez a művelet mozgásba hozza a teljes metamorf szerződés létrehozási folyamatát.

Minden, ami ezután következik, ennek a kezdeti lépésnek az eredménye. Valóban, Az 1–6. lépés a blokklánc egyetlen atomtranzakciójában történik, vagyis szinte egyszerre. Ezek a lépések újra és újra megismételhetők, a végtelenségig, hogy lecseréljék a Metamorphic Contract-ben lévő kódot, és folyamatosan változtassák.

2. lépés: A gyár telepíti a megvalósítási szerződést

Az első szerződés, amelyet a gyár telepít, az Implementation Contract, amely tartalmazza a megvalósítási kódot. (Kreatív, tudjuk.) Tekintsünk a megvalósítási szerződésre úgy, mint egy rakodódokkra vagy útpontra, amely tartalmaz egy kódot, mielőtt a végső rendeltetési helyére szállítaná, ami ebben az esetben a metamorf szerződésen belül lesz. 

3. lépés: A gyári üzletek a megvalósítási szerződés címét

A blokkláncon való üzembe helyezés után az implementációs szerződés szükségszerűen létezni fog valamilyen blokklánc címen. A Gyár ezt a szerződéscímet a saját memóriájában tárolja (a későbbiekben, az 5. lépésben használható fel). 

4. lépés: A gyár telepíti a Metamorphic Contract-ot

A gyár a Metamorphic Contract-ot CREATE2 és metamorf bájtkód használatával telepíti. Technikai, mélyreható áttekintést találhat a metamorf bájtkód működéséről itt, de elég annyit mondani, hogy amikor a metamorf bájtkód végrehajtódik, akkor a láncon belüli másik helyről – jelen esetben a megvalósítási szerződésből – másolja a kódot a metamorf szerződésbe. Amint arról az utolsó részben beszéltünk, mivel a CREATE2 determinisztikus – mindaddig, amíg ugyanazt a feladót, sót és bájtkódot használja –, a Metamorphic Contract címe változatlan marad, függetlenül attól, hogy hányszor ismétlődnek meg ezek a lépések.

Az alábbiakban egy példa látható arra, hogyan néz ki a metamorf bájtkód, a metamorf repo 0 éves korig. Ez csak egy példa a metamorf bájtkódra – potenciálisan számtalan változat létezik, ami nagymértékben megnehezíti a metamorf szerződések észlelését.

5. lépés: Metamorf bájtkód lekérdezések A Factory for Implementation szerződés címe

A metamorf bájtkód kéri a gyártól a megvalósítási szerződés címét (a 3. lépésben tárolva). Nem számít, ha a Megvalósítási Szerződés címe megváltozik, amíg a címet kérő metamorf bájtkód változatlan marad. Valójában, ha a fejlesztő később telepít egy új megvalósítási szerződést – például egy tokenek ellopására tervezett rosszindulatúat –, akkor az szükségszerűen egy másik blokklánc-címen lesz telepítve a 2. lépésben. Ez nincs hatással a Metamorf Szerződés létrehozására.

Lépés 6: Az implementációs szerződés kódja be lesz másolva a metamorf szerződésbe

Az 5. lépésben megtanult blokklánc-cím használatával a metamorf bájtkód megkeresi a kódot a megvalósítási szerződésben, és bemásolja a kódot a metamorf szerződés helyi tárolójába. Így változik a Metamorphic Contract alakja: a végrehajtási szerződés kódjának másolásával. 

7. lépés: Öblítse le és ismételje meg

A fejlesztő újra és újra megismételheti az 1–6. lépéseket, és lecserélheti a Metamorphic Contract kódját tetszőlegesre egy új megvalósítási szerződés révén. Mindössze a SELFDESTRUCT műveleti kód használatára van szükség – vagy még inkább a DELEGATECALL műveleti kódokra, amelyek végül SELFDESTRUCT-ot eredményeznek –, hogy eltávolítsák a Metamorphic Contract már meglévő kódját. A ciklus új Implementation Contract bájtkóddal történő megismétlésével a metamorf szerződés varázslatszerűen morph!

Ezzel a metamorf szerződések létrehozására szolgáló technikával egy okos fejlesztő folyamatosan áthelyezheti a talajt a web3 felhasználók lába alatt. Vegyük például újra az átverés forgatókönyvét. A fejlesztő először telepítheti a megvalósítási szerződést egy token-kiosztású kóddal, amely az ábrán látható és a fenti lépésekben kidolgozott körös útvonalon keresztül a metamorf szerződésbe kerül. A csaló később önmegsemmisítheti ezt a kódot, és lecserélheti egy új, tokent tartalmazó végrehajtási szerződés bevezetésével.lopás kód. 

Bármi is kerül beépítésre a megvalósítási szerződésbe, az végül a metamorf szerződésbe kerül. Ez a trükk lényege. 

***

A metamorf intelligens szerződések megtörik az implicit web3 közösségi szerződést, miszerint amit látsz, azt kapod. Hasonlóan ahhoz, ahogy a kagylójáték három mozgó poharat használ egy labda elrejtésére, a három szerződés kölcsönhatása a metamorf szerződés létrehozásában megnehezíti a szerződés valódi funkciójának követését. A shell-játék különösen találó összehasonlítás, mert az önbizalom csalók gyakran ravaszságot és félrevezetést alkalmaznak a győzelem biztosítására. A web3-as verzióban a metamorf szerződésírók hasonlóképpen eltüntethetik (értsd: önmegsemmisíthetik) a „labdát” – az implementációs kódot, és azt bármivel helyettesíthetik.

A metamorf szerződések megléte azt jelenti, hogy a web3 felhasználók olyan szerződéseket köthetnek, amelyek tetszés szerint változhatnak – ezért olyan fontos megérteni ezt a fenyegetést, és védekezni ellene. Az én metamorf szerződés detektorom csak az első lépést kínálja a metamorf szerződések beazonosításához az általuk alkalmazott kézügyesség alapján. Az érzékelőt a jövőben többféleképpen is lehet fejleszteni. Például a Metamorphic Contractot létrehozó gyári (vagy telepítői szerződés) rekurzív ellenőrzésével láthatja, hogy a gyár maga metamorf-e. Ez a funkció hasznos kiegészítője lenne a Detector frissített 2-es verziójának.

Érdemes még egyszer megismételni: ez a Detector eszköz nem bolondbiztos. A zászlók, amelyeket elkap, nem mind árulkodó jelei a metamorf potenciálnak, de nyomokat adnak. Ezeknek a zászlóknak az azonosítása csak a kezdete egy alaposabb vizsgálatnak. Ezért bővítettük az érzékelőt, hogy olyan jelzőket keressen, amelyek könnyen hamis pozitív eredményeket generálhatnak, mint például a CREATE2 vagy DELEGATECALL műveleti kódok jelenléte. Ha javaslatai vannak az eszköz javítására, vagy tovább szeretné építeni ezt a kezdeti munkát, vagy kiegészíteni szeretné azt, lépjen kapcsolatba velem a következő címen: .

Elemezze az intelligens szerződéseket metamorf tulajdonságok szempontjából a Detector eszközzel és látogasson el a GitHub repo tovább

Vágó: Robert Hackett @rhhackett

***

Köszönetnyilvánítás: ÓRIÁSI köszönetet szeretnék mondani Robert Hackettnek, Eddy Lazzarinnak, Sam Ragsdale-nek, Riyaz Faizullabhoynak, Noah Citronnak, Mason Hallnak és Daejun Parknak az értékes visszajelzésekért és tanácsokért a bejegyzés és az eszköz életre keltésében. 

***

Az itt kifejtett nézetek az AH Capital Management, LLC („a16z”) egyes alkalmazottainak nézetei, és nem az a16z vagy leányvállalatai nézetei. Az itt található bizonyos információk harmadik féltől származnak, többek között az a16z által kezelt alapok portfólióvállalataitól. Noha megbízhatónak vélt forrásokból származnak, az a16z nem ellenőrizte önállóan ezeket az információkat, és nem nyilatkozik az információk tartós pontosságáról vagy adott helyzetre való megfelelőségéről. Ezenkívül ez a tartalom harmadik féltől származó hirdetéseket is tartalmazhat; az a16z nem vizsgálta át az ilyen hirdetéseket, és nem támogatja az abban található reklámtartalmat.

Ez a tartalom csak tájékoztatási célokat szolgál, és nem támaszkodhat rá jogi, üzleti, befektetési vagy adótanácsadásként. Ezekkel a kérdésekkel kapcsolatban konzultáljon saját tanácsadójával. Bármely értékpapírra vagy digitális eszközre történő hivatkozások csak illusztrációs célt szolgálnak, és nem minősülnek befektetési ajánlásnak vagy ajánlatnak befektetési tanácsadási szolgáltatások nyújtására. Ezen túlmenően ez a tartalom nem befektetőknek vagy leendő befektetőknek szól, és nem is szánható felhasználásra, és semmilyen körülmények között nem támaszkodhat rá az a16z által kezelt alapokba történő befektetésről szóló döntés meghozatalakor. (A16z alapba történő befektetésre vonatkozó ajánlatot csak az ilyen alap zártkörű kibocsátási memoranduma, jegyzési szerződése és egyéb vonatkozó dokumentációja tesz, és azokat teljes egészében el kell olvasni.) Minden említett, hivatkozott befektetés vagy portfóliótársaság, ill. A leírtak nem reprezentatívak az a16z által kezelt járművekbe történő összes befektetésre, és nem garantálható, hogy a befektetések nyereségesek lesznek, vagy a jövőben végrehajtott egyéb beruházások hasonló tulajdonságokkal vagy eredménnyel járnak. Az Andreessen Horowitz által kezelt alapok befektetéseinek listája (kivéve azokat a befektetéseket, amelyek esetében a kibocsátó nem adott engedélyt az a16z számára a nyilvánosságra hozatalra, valamint a nyilvánosan forgalmazott digitális eszközökbe történő be nem jelentett befektetéseket) a https://a16z.com/investments oldalon érhető el. /.

A benne található diagramok és grafikonok kizárólag tájékoztató jellegűek, és nem szabad rájuk hagyatkozni befektetési döntések meghozatalakor. A múltbeli teljesítmény nem jelzi a jövőbeli eredményeket. A tartalom csak a feltüntetett dátum szerint beszél. Az ezekben az anyagokban megfogalmazott előrejelzések, becslések, előrejelzések, célok, kilátások és/vagy vélemények előzetes értesítés nélkül változhatnak, és mások véleményétől eltérhetnek vagy ellentétesek lehetnek. További fontos információkért látogasson el a https://a16z.com/disclosures oldalra.