Trendande ämnen
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
Across V4 introducerar en ny och förbättrad crosschain-arkitektur.
Systemet kombinerar avsikter och nollkunskapsbevis (ZKP) för att expandera till fler kedjor, snabbare.
Här är den tekniska uppdelningen. 🧵

Tidigare använde Across "kanoniska bryggor" eller kedjespecifika adaptrar för att verifiera meddelanden från Ethereums HubPool.
Detta fungerade bra för L2:er som Arbitrum och Optimism, som exponerar Ethereum-slutfört tillstånd.
Men den här designen var begränsande...
För icke-EVM-kedjor som BSC går den här modellen sönder.
Det finns inget kanoniskt sätt att verifiera Ethereums tillstånd. Detta innebar antingen att man byggde anpassade adaptrar eller inte stödde dessa kedjor alls.
Ingen av dessa är optimala lösningar. Så vi kom på ett bättre sätt att använda ZKP:er.
Så här går det till:
När förmedlare fyller crosschain-order batchas transaktionerna i relayer-återbetalningsbuntar, som sedan verifieras av @UMAProtocol:s Optimistic Oracle.
Detta händer alltid på Ethereums huvudnät.

När ett paket har verifierats utlöser Across HubPool avvecklingsprocessen.
Den skriver sedan återbetalningsmeddelandets hashvärden till HubPoolStore-kontraktet på specifika lagringsplatser.
Denna lagringshändelse sker också på Ethereums huvudnät.
Varje meddelandehash i HubPoolStore-kontraktet motsvarar en avsikt att återbetala en vidarebefordrare i en målkedja.
Observera att L1- → L2-meddelanden kan representera flera återbetalningar (inklusive långsamma fyllningar). Detta beror på att de är rotbuntar.
När HubPoolStore-kontraktet skriver en lagrad meddelandehash genererar det en StoredCallData-händelse.
Den här händelsen innehåller meddelandets hash och lagringsfack.
Händelsen + lagrade data utgör fästpunkten för ZK-verifiering nedströms.
En tjänst som kallas finalizer lyssnar efter dessa händelser.
När den upptäcker en ny initierar den en process för att bevisa att meddelandehashen verkligen skrevs på Ethereum.
Varje meddelande som hashen lagras för har ett mål som kan vara specifikt för dess kedja.
Med det här beviset kan meddelandet köras på ett säkert sätt i målkedjan.
Men Ethereums slutgiltighet är inte omedelbar.
När färdigställaren skickar data till ZK API, väntar API:et genom Ethereums slutgiltighetsfönster innan det genererar ett bevis.
För att generera ett giltigt ZK-bevis måste Ethereum-synkroniseringskommittén godkänna ett specifikt slutfört block.
Om meddelandet ingick i eller före det blocket blir de signaturer som krävs för att börja generera ZK-beviset.
Färdigställaren frågar ZK API för att generera ett bevis på att en specifik meddelandehash har skrivits till en känd HubPoolStore-lagringsplats i ett slutfört Ethereum-block.
Detta möjliggör tillförlitlig verifiering av relayer-återbetalningar på alla destinationskedjor.

ZK API förbereder bevisindata inklusive (men inte begränsat till):
- Slutförda beacon-huvuden
- Synkronisera kommittésignaturer
- Merkle bevis för lagring från Ethereums exekveringslager
Dessa utgör grunden för att generera beviset.
Across distribuerar en allmän stack i målkedjor:
- Ett verifieringskontrakt (validerar ZK-beviset)
- SP1Helios av @Succinct (lagrar slutfört Ethereum-tillstånd)
- UniversalSpokepool-kontrakt (verifierar äktheten av meddelanden under körning)

När ZK-beviset har verifierats och tillståndet har bekräftats kan executeMsg() köra nyttolasten på ett säkert sätt i målkedjan.
Pålitlig. Säker. Universell.
Detta innebär att Across inte längre behöver anpassade adaptrar för varje kedja.
Bara en pipeline som fungerar överallt:
storeMsg() på Ethereum → ZK-bevis → executeMsg() på alla destinationskedjor som kan verifiera SP1Helios-beviset.

Inga förtroendeantaganden.
Inga integrationskostnader.
Bara avsikter + ZK.
Varför är detta en stor sak?
Det utökar dramatiskt Across' räckvidd genom att låsa upp stöd för långa svanskedjor som inte kan verifiera Ethereums tillstånd inbyggt och inte har kanoniska broar.
Detta gör onboardingen snabbare, säkrare och mer skalbar.
Across behöver inte en kanonisk bro för dessa kedjor. Den behöver bara kunna verifiera ett ZK-bevis på Ethereum-tillståndet.
Detta minskar integrationskostnaderna, undviker centraliserade överbryggningsrisker och förstärker Ethereums roll som roten till sanningen över kedjan.
6,71K
Topp
Rankning
Favoriter