Brainstorm-to-improve-UX: Helt siden jeg migrerte til mempool-basert sekvensering med 0.14, får jeg milde vibber av uklarhet rundt hvilke transaksjoner som er i mempoolen og når jeg skal sende transaksjoner på nytt (forutsatt at ingen gebyrøkning er ønsket). Nærmere bestemt kan transaksjoner stille falle ut av mempoolen når det er overbelastning uten varsel til avsenderen. Er dette noe du lider av? Noen anbefaling eller referanse til en DESENTRALISERT kjede som har en fin løsning på dette problemet? For eksempel kan teamet eksternalisere status for transaksjoner i mempoolen fra én tilfeldig node, men dette vil ikke være en fremtidskompatibel løsning fordi når det er en desentralisering, kan hver node implementere sin egen slipppolicy. (Og til og med på kort sikt kan det være korte forskjeller mellom utløp på forskjellige noder som kan føre til inkonsekvenser)

Hadde et møte i går med en talentfull ingeniørteamleder som i løpet av de neste månedene vil overvåke "EchoNet"-utviklingen. "EchoNet" er et internt prosjekt. Starknet-brukere vil aldri føle det. Markedsføring vil ikke nevne det. Likevel begeistrer det meg veldig. Betydningen - det vil gjenta alle hovednett-txer til et testmiljø som har den nye utgivelseskandidaten, og vil automatisk oppdage eventuelle hull i utførelsen kontra det nåværende hovednettet. Dette vil avdekke mange kanttilfeller som kan forårsake avvik før en versjon utgis. EchoNet vil i stor grad hjelpe oss med å fortsette og utvikle SN med vakre funksjoner, samtidig som vi opprettholder stabiliteten som en moden kjede bør ha. Å ha testnett for e2e-sjekker er ikke lenger nok.

Teamet oppdaterte i dag det interne integrasjonsmiljøet til 0.14.1. Testnett, og deretter Mainnet, er ventet om noen uker. 0.14.1 er et mellomstort skritt for Starknet, men i dag fokuserer jeg på at det representerer et stort tankeskifte i Starknet-utviklingen. Vi hadde store store endringer tidligere, noe som tvang apper til å jobbe hardt for å holde seg på plass. Men etter hvert som Starknet modnes, og har som mål å være det beste stedet å bygge videre på, kan ikke dette fortsette. 0.14.1 representerer dette, og her er grunnen Med utgivelsen av S-Two ble noen hashes som ble valgt for å passe Stone relativt dyre. Disse hashene brukes overalt, fra hashing av anropsdata til lesing og skriving. 0.14.1 sa ikke: "La oss endre alle hashes vi kan for å være de billigste der ute og tvinge alle til å tilpasse seg". Den sier: la oss migrere, forsiktig, bare stedene byggherrer ikke vil føle og er for det meste under panseret. La oss deretter koordinere med SDK-er for å sikre at utviklere virkelig ikke føler noe (så lenge de oppdaterer SDK-en sin noe regelmessig). Helvete, la oss på forhånd forberede en liste over transaksjoner som kun tar sikte på å migrere disse hashene, som en del av oppgraderingsprosessen, for å sikre at enhver tx som var gyldig før fortsatt vil være gyldig, uten at noen trenger å løfte en finger Jeg kan ikke garantere at det aldri vil bli en ny banebrytende endring i Starknet. Men jeg kan garantere at denne tankegangen er kommet for å bli.