Cardano traži standard za softver proizvođača blokova

Cardano Problem Statement traži zajedničku metodu za identifikaciju softvera koji se koristi za proizvodnju pojedinačnih blokova. Rasprava o CPS-0036 otvorena je 2. rujna i 16. rujna dobila oznaku Confirmed, ali prijedlog ostaje otvoren i ne uspostavlja tehnički standard.

Svrha mu je definirati problem prije nego što zaseban Cardano Improvement Proposal odredi format signaliziranja, registar softvera i pravila implementacije.

Cardano se širi izvan jedne implementacije čvora

Cardano se povijesno oslanjao na Haskellom utemeljeni cardano-node, dok se sada razvijaju dodatne implementacije prema istim pravilima konsenzusa. CPS-0036 navodi Amaru i Dingo, a u raspravi o prijedlogu spominje se i Gerolamo.

U ovom kontekstu, klijent je softver čvora koji validira Cardano protokol i može sudjelovati u proizvodnji blokova. Odvojen je od novčanika i drugih aplikacija koje se koriste za interakciju s mrežom.

Neovisne implementacije mogu poboljšati otpornost jer nedostatak koji pogađa jednu bazu koda možda ne postoji u drugoj. Ta korist ovisi o usvajanju. Ako jedan klijent nastavi proizvoditi većinu blokova, mreža ostaje operativno ovisna o toj implementaciji čak i kada su dostupne alternative.

Cardano trenutno nema standardizirano polje koje pripisuje svaki blok softveru koji ga je stvorio. Istraživači, exploreri i platforme za nadzor moraju neizravno procjenjivati raspodjelu klijenata, stvarajući skupove podataka koji mogu biti nepotpuni ili teško usporedivi.

Aktivnost na mreži učinila je pitanje hitnijim. Recenzent yHSJ rekao je da su Dingo i Gerolamo već proizveli blokove koristeći polje minor verzije protokola kao identifikator softvera, dok Amaru planira slijediti isti pristup.

CPS-0036 opisuje dobrovoljno signaliziranje softvera

CPS-0036 poziva na kompaktan, dobrovoljan i konsenzusno neutralan mehanizam. Blokovi bez identifikatora softvera ostali bi valjani, a svaki operater stake poola odlučivao bi hoće li objaviti informaciju.

Rasprava opisuje dva postojeća pristupa. Jedan koristi četiri bajta iz polja minor verzije protokola u zaglavlju bloka. Drugi koristi označnu transakciju od približno 60 bajtova. Bez zajedničke specifikacije, implementacije bi mogle usvojiti različite formate i prisiliti pružatelje infrastrukture da održavaju odvojena pravila dekodiranja.

Prijedlog također poziva na javno upravljani registar koji svakoj implementaciji dodjeljuje prepoznatljiv identifikator. Exploreri, istraživači i nadzorne ploče tada bi mogli tumačiti signal dosljedno na cijeloj mreži.

Identitet klijenta prvi je predloženi slučaj upotrebe. Mehanizam bi kasnije mogao podržati izjave o dostupnosti značajki ili spremnosti softvera prije nadogradnji protokola.

Nekoliko dizajnerskih pitanja ostaje neriješeno. Samoproglašeni identifikator može se krivotvoriti, dok bi njegovo kriptografsko vezivanje uz KES ili VRF vjerodajnice dodalo složenost. Objavljivanje detaljnih verzija softvera također bi moglo izložiti operatere koji koriste ranjiva izdanja. Svaka specifikacija trebala bi ostati kompatibilna s Leiosom i njegovom razvijajućom strukturom blokova.

Podaci o klijentima mogli bi ojačati nadzor Cardano mreže

Standardni identifikator omogućio bi Cardanu mjerenje deklarirane raznolikosti klijenata izravno iz proizvedenih blokova. Operateri mreže i istraživači mogli bi izračunati udio povezan s pojedinom implementacijom, identificirati pretjerano oslanjanje na jednu bazu koda i pratiti prelaze li alternativni klijenti u aktivnu infrastrukturu.

Podaci bi također mogli podržati nadogradnje protokola. Ako standard kasnije uključi spremnost značajki, ekosustav bi mogao dobiti pogled na razini mreže prije hard forka ili većeg izdanja softvera. Testiranje i koordinacija ostali bi odvojeni procesi, dok bi signal na lancu pružio zajednički operativni skup podataka.

Rasprava upućuje na to da se praktična konvencija možda već formira oko polja minor verzije protokola. Urednik CIP a Robert Phair rekao je da bi na rješenje usmjeren CIP, utemeljen na trenutačnoj praksi, mogao pružiti izravniji put nego samo dokumentiranje problema.

Softversko signaliziranje ne može stvoriti raznolikost klijenata niti spriječiti kvarove, ali može olakšati mjerenje Cardanove infrastrukture. Ako bude usvojen, standard bi omogućio explorerima i alatima za nadzor da zamijene fragmentirane procjene dosljednim podacima na razini bloka o tome koji deklarirani klijent proizvodi blokove mreže.