Dosari katika XRP Ledger ingeweza kuunda XRP ambazo kwa kawaida haziruhusiwi kutolewa na itifaki. Dosari hiyo ilirekebishwa katika xrpld 3.4.1 na kufichuliwa tarehe 9 Oktoba. Timu za mtandao zinasema hazikupata ushahidi wowote wa kutumiwa kwa dosari hiyo kwenye mtandao wa hadharani.
Hatari hiyo ilihusu uadilifu wa sarafu yenyewe, si wallet pekee. Tukio hilo pia linaibua swali la utawala: unawezaje kusambaza marekebisho ya dharura bila kuacha uwezekano wa dosari kutumiwa wakati validators wanapiga kura?
Kwa ufupi
- Veria Labs inaeleza jaribio lililoweza kuunda takriban trilioni 18,450 za XRP katika mazingira ya majaribio.
- Marekebisho hayo yalisambazwa kabla ya maelezo kuchapishwa; timu hazikutambua unyonyaji wowote wa hadharani.
- Waendeshaji wanapaswa kutumia xrpld 3.4.1 au toleo linalofuata linalooana.
XRP: Namba ya kushangaza, si wizi uliothibitishwa
Matengenezo ya itifaki yalikuwa tayari yamejadiliwa katika pendekezo la kuondoa bridge ya asili ya XLS-38 kwenye XRP Ledger. Safari hii, suala linahusu moja kwa moja uwezekano wa kuunda asset asilia. Hii si token ya mtu mwingine inayojifanya kuwa na jina hilo.
Katika uchambuzi wake wa kiufundi uliochapishwa tarehe 10 Oktoba, Veria Labs inakadiria jaribio hilo kuwa takriban XRP trilioni 18,446.7. Ikilinganishwa na jumla ya awali ya vitengo bilioni 100, hiyo ni takriban mara 184 ya supply ya mwanzo. Huu ni ulinganisho wa kiasi, si makadirio ya mapato ambayo yangeweza kupatikana.
Veria pia inataja market cap ya dola bilioni 94 kama thamani ambayo ingeweza kuwa hatarini. Kiasi hicho si hasara iliyothibitishwa. Utoaji mkubwa kama huo wa ulaghai ungeweza kuathiri imani na bei; hakuna kinachoruhusu kuthibitisha kwamba vitengo hivyo vingepata wanunuzi kwa bei ya kabla ya tukio.
Ripoti rasmi ya ufichuzi inatofautisha wazi uwezo ulioigwa kwenye majaribio na unyonyaji wa hadharani. Hata hivyo, kutokuwepo kwa ushahidi ulioripotiwa si hakikisho kamili kuhusu historia yote ya mtandao.
Ukaguzi wawili ulipotoshwa na hesabu ileile
Veria inaeleza kwamba tatizo lilikuwa katika kujumlisha kiasi wakati wa kuchakata orders. Namba ya kompyuta ina uwezo mdogo; ikiwa programu haikagui overflow, matokeo yanaweza kuwa yasiyo sahihi. Katika hali hii, jumla iliyokatwa ingeweza kutolingana na kiasi kilichowekwa.
Nyaraka za invariants za XRPL zinaeleza kwamba kuna ukaguzi wa pili unaofanywa kabla mabadiliko hayajaandikwa. Ukaguzi huo unapaswa, miongoni mwa mambo mengine, kuzuia transaction kuunda XRP na kuthibitisha mipaka ya salio.
Ulinzi miwili si lazima iwe kinga mbili huru. Kulingana na uchambuzi wa Veria, ukaguzi wa jumla pia ulitumia counter iliyoweza ku-overflow. Hivyo ungeweza kuidhinisha matokeo ya kihasibu yaliyokuwa tayari yamepotoshwa. Somo hili linavuka itifaki hii: kupima kanuni ya biashara hakutoshi ikiwa ukaguzi wake unashiriki udhaifu wa hesabu ya mwanzo.
Hii ni tofauti muhimu na ruhusa za kuunda tokens katika smart contract. Utoaji unaoruhusiwa na administrator na utoaji unaotokana na hitilafu ya engine ya asili ni matatizo mawili tofauti.
Kwa nini dharura ilivuruga mchakato wa kura
Mchakato wa kawaida wa amendment unahitaji uungwaji mkono wa zaidi ya 80% ya validators wanaoaminika kwa muda wa wiki mbili. Faida yake ni ya moja kwa moja: kanuni mpya inatumika katika sehemu ileile ya historia, badala ya kuacha matoleo mbalimbali yashughulikie transaction moja kwa njia tofauti.
Uratibu huo unaangazia mjadala kati ya udhibiti wa uendeshaji na decentralization. Kasi ya uamuzi, yenyewe, haisemi ni nani anayeweza kuweka kanuni za mtandao kwa kudumu.
Kwa dosari ya utoaji, timu zilichagua kuitekeleza mara moja baada ya sasisho. Zinaeleza kwamba kusubiri kungeifanya bug ijulikane hadharani kabla ya kuzuiwa. Uamuzi huo uliunda hatari ya muda ya kutokubaliana kati ya matoleo, hatari iliyokubaliwa kutokana na kuzingatia tishio la utoaji wa ulaghai.
Suala hili lina uhusiano, bila kuchanganya miundo hiyo, na mijadala kuhusu hatua za dharura baada ya hack. Suala si uwezo wa kuchukua hatua haraka pekee, bali pia kueleza ni ubaguzi gani unatumika na kwa nini.
Marekebisho mawili, ratiba mbili
Tangazo la tarehe 25 Septemba liliwasilisha toleo la 3.4.1 kama release ya dharura. Tayari lilieleza kuimarishwa kwa hesabu za arithmetiki, lakini kwa muda lilizuia code ya chanzo kwa sababu za usalama.
Ripoti ya Oktoba pia inashughulikia hitilafu nyingine inayohusiana na namna transactions za Batch zinavyofungwa. Hitilafu hiyo haikuathiri fedha kwenye mainnet kabla ya kurekebishwa. Ilifuata ratiba tofauti: amendment fixBatchV1_2 ilianza kutumika tarehe 9 Oktoba.
Kwa hiyo, matukio hayo mawili hayapaswi kuunganishwa. Marekebisho ya payment engine yalitumika pamoja na sasisho la server; mabadiliko mengine yalitegemea kuamilishwa kwa amendment.
Waendeshaji wanapaswa kukagua nini
Release ya sasa kwenye GitHub inathibitisha kwamba matoleo ya zamani yasiyokuwa na amendment mpya sasa yamezuiwa kufuatilia mtandao. Hatua inayotarajiwa inawahusu waendeshaji wa servers: kusasisha programu zao, kisha kuthibitisha synchronization yake na mwendelezo wa huduma.
Nyaraka zinakumbusha kwamba server iliyozuiwa na amendment haiwezi tena kubaini kwa usahihi uhalali wa ledgers au kushiriki katika consensus. Hivyo, application inaweza kuwa na interface inayofanya kazi huku ikitegemea server ambayo imekuwa isiyofaa.
Kwa msomaji, ukaguzi muhimu ni tofauti: kutenganisha marekebisho yaliyosambazwa kwa kweli, jaribio la utafiti na tukio la kifedha lililothibitishwa. Uchambuzi wetu unategemea nyaraka za maintainers na watafiti; hatukutekeleza jaribio lao kwa kujitegemea.
Kinachofuata kinapaswa kupimwa kwa ubora wa deployment na ukaguzi, si kwa idadi pekee ya XRP ambazo kinadharia zingeweza kuundwa. Kanuni ya supply iliyowekewa kikomo inaaminika tu ikiwa programu inayoitekeleza, safeguards zake na taratibu za kusasisha vinafanya kazi kwa pamoja.
