Bitcoin Core v32 RC1: raktų atnaujinimo suderinamumo patikrinimai
Bitcoin Core v32.0rc1 tapo rugsėjo 14–spalio d. 10 langas į koncentruotą suderinamumo testą mazgų operatoriams, piniginės tiekėjams ir paslaugoms, kurios priklauso nuo Bitcoin Core RPC sąsajų.
Rugsėjo 14 d. kandidatas buvo pažymėtas patvirtintu parašu. Tiesioginio išleidimo tvarkaraštyje nurodyta, kad spalio 10 d. yra galutinis v32.0 žymos tikslas, paliekant 26 dienų intervalą. „CryptoSlate“ rugpjūčio mėnesio peržiūra užfiksavo rugsėjo 10 d. RC1 tikslą, o tiesioginiame tvarkaraštyje dabar rodoma rugsėjo 14 d., todėl susidaro keturių dienų neatitikimas, nenustačius, kad nepakeistas terminas buvo praleistas.
Žyma v32.0rc1 identifikuoja išankstinio leidimo programinę įrangą, o ne galutinį gamybos atnaujinimą. Tai taip pat nerodo naujo sutarimo taisyklės aktyvavimo. Vienas pakeitimas, susijęs su BIP 323 projektu, pakeičia tai, kaip „Bitcoin Core“ apdoroja signalinius bitus ir įspėjimus apie nežinomą diegimą, tačiau pats pasiūlymas išlieka juodraščio būsena.
Operatoriai gali pradėti nuo aukščiausio lygio modelio naujausiame Bitcoin Core RC testavimo vadove: naudotis reguliariai naudojamomis funkcijomis atskiruose laikinuosiuose duomenų kataloguose ir palyginti kandidatą su ankstesniu leidimu. Oficialiame atsisiuntimo puslapyje kaip dabartinė bazė nurodyta 31.1. Šis palyginimas gali atskleisti mazgo paleidimo, piniginės elgsenos ir RPC atsakymų skirtumus, nelaikant kandidato įprastu gamybos atnaujinimu.
Didžiausias našumo pokytis 32 versijos leidimo pastabų juodraštyje yra lygiagretus išankstinis operacijų išėjimų gavimas blokinio ryšio metu. Numatytasis nustatymas yra aštuoni darbuotojai, palaiko iki 16 ir gali būti išjungtas. Vykdant diske susietą patvirtinimą su keliais nustatymais gali paaiškėti, ar spartesnis blokų apdorojimas susijęs su nepriimtinomis operatoriaus aparatūros procesoriaus, atminties ar saugojimo delsos sąnaudomis.
Piniginės ir paslaugų integravimas susiduria su atskira gedimo rizika. Keturiuose RPC pagal numatytuosius nustatymus bus nustatytas PSBTv2, o kitos sąsajos pašalina nebenaudojamus laukus arba atmeta argumentus, kuriuos toleravo senesnės versijos. Todėl komandos, kuriančios, konvertuojančios ar apmokestinančios PSBT, turėtų atsekti šias operacijas per savo paskesnius analizatorius ir pasirašiusius.
Mokesčių tvarkymui taip pat reikia gedimo kelio aprėpties. Numatytoji estimatesmartfee kelias sujungia bloko politikos ir atmintinės įverčius, gali pateikti mažesnį įvertinimą ir gali suklysti, jei kuris nors komponentas sugenda. Operatoriai turėtų stebėti paleidimo ir retų arba nesveikų duomenų kaupimo sąlygas, tada patvirtinti, kad stebėjimas ir aiškūs blokų politikos atsarginiai veiksmai veikia taip, kaip tikėtasi.
HTTP serverio perrašymas išplečia bandymo paviršių už paties mazgo. Pridedamas 8 192 baitų antraštės limitas, griežtesnis netinkamai suformuotų antraščių tvarkymas, numatytoji 16 RPC jungčių riba, nauji REST talpyklos valdikliai ir nedelsiant atjungiami neteisėtų klientų adresai. Šie pakeitimai gali atsirasti atvirkštiniuose tarpiniuose serveriuose, sveikatos patikrinimuose, klientų telkiniuose ir klaidų tvarkyklėse.
Atšaukimas nusipelno tiek pat dėmesio. Atnaujintas operacijų indeksas sunaudoja mažiau nei pusę vietos diske, tačiau senesni leidimai negali nuskaityti naujo formato, todėl atnaujinimas gali sukelti kitą atkūrimą, kuris trunka valandas. Į privatumą orientuoti operatoriai taip pat turėtų atkurti privataus transliavimo gedimų kelius, susijusius su Tor atsarginiu pataisymu, 10 000 įrašų eilutę, 1 000 bandymų limitą ir perdavimo veikimą esant apkrovai. Kadangi galutinė žyma vis dar yra tik tikslas, šie kraštiniai atvejai yra praktinis RC lango darbas.
