Wie Blockchains miteinander kommunizieren

Als Blockchains zum ersten Mal erstellt wurden, wurde davon ausgegangen, dass sie eine "One Size Fits All" -Lösung bieten können, was bedeutet, dass alle Transaktionen, intelligenten Verträge oder alles andere in einer einzigen Kette ausgeführt werden. Es ist jedoch jetzt klar, dass ein solches System nicht so praktisch ist, insbesondere wenn es Skalierbarkeitsgrenzen und Innovationsbeschränkungen gibt.

Eine Kreuzkette ist die Interoperabilität zwischen zwei relativ unabhängigen Blockketten. Mit anderen Worten, es ermöglicht Blockchains, miteinander zu sprechen, da sie auf standardisierte Weise aufgebaut sind. Die kettenübergreifende Implementierung wird hauptsächlich durch Asset-Swap und Asset-Transfer repräsentiert, die sowohl ein wichtiger Bestandteil der Blockchain-Welt als auch eine wichtige Forschungsrichtung von PPIO sind. Mit Kreuzketten können die Einschränkungen einer einzelnen Kette vermieden werden. Heute werden wir die logische Struktur des Cosmos Cross-Chain-Protokolls untersuchen, einer der vielversprechendsten Cross-Chain-Plattformen.

Die Kreuzkettenwechselwirkung kann entsprechend der zugrunde liegenden Technologie in isomorphe Kreuzketten und heterogene Kreuzketten unterteilt werden. Bei isomorphen Ketten sind der Sicherheitsmechanismus, der Konsensalgorithmus, die Netzwerktopologie und die Blockgenerierungsverifizierungslogik konsistent und die kettenübergreifende Interaktion zwischen ihnen ist relativ einfach.

Andererseits ist die kettenübergreifende Wechselwirkung heterogener Ketten relativ komplex und umfasst Technologien wie den PoW-Algorithmus für Bitcoin und den PBFT-Konsensus-Algorithmus für Tendermint. Die Blockzusammensetzung und der deterministische Garantiemechanismus sind sehr unterschiedlich, daher ist ein Mechanismus für direkte kettenübergreifende Wechselwirkungen nicht einfach zu entwerfen. Die kettenübergreifende Interaktion zwischen heterogenen Ketten erfordert im Allgemeinen Nebendienstleistungen von Drittanbietern.

Auf Tendermint-Basis entwickelte Ketten können übernehmen isomorphe Kreuzketten. Das Prinzip des Asset-Transfers zwischen isomorphen Ketten im Kosmos lautet wie folgt.

Da Tendermint den PBFT + POS-Konsensalgorithmus verwendet, wird ein Block nur dann an das Netzwerk gesendet, wenn 2⁄3 Zertifizierer zustimmen. Die Validator-Informationen können überprüft werden, indem der Blockheader überprüft wird, um zu überprüfen, ob der Blockheader in einer bestimmten Kette zulässig ist. Als Beispiel entwickelt Tendermint zwei Ketten: Kette A und Kette B. Nehmen wir nun an, dass Vermögenswerte über die Kette übertragen werden müssen. Erstens registrieren sich die beiden Ketten A und B miteinander. Bei der Registrierung erkennen A und B ihre Trennung. Die Kette sendet dann die entsprechenden Genesis-Blöcke und die ChainID (zur Darstellung verschiedener Ketten) aneinander. Da der Genesis-Block die Validator-Informationen enthält, enthalten die Ketten A und B nach der Registrierung die Validator-Informationen der anderen Kette sowie die Block-Header-Informationen.

Nun müssen die Assets in A an B übertragen werden. Zuerst kann der Benutzer eine kettenübergreifende Transaktion packageTx an A senden. A führt packageTx aus, zerstört oder sperrt die zugehörigen Assets und schreibt packageTx dann in den Ausgang. Der Ausgang kann als eine Mailbox betrachtet werden, in der alle extern gemeldeten kettenübergreifenden Transaktionen abgelegt werden.

Um die Kette B über Ereignisse in der Kette A zu informieren, wird ein Relayer benötigt. Der Relayer ist für die Weiterleitung kettenübergreifender Nachrichten vom Ausgang in Kette A zum Ausgang von Kette B verantwortlich. In dieser Situation fragt der Relayer das packageTx in der Kette A ab und erhält den Merkle Proof von packageTx. Die Informationen werden in die PostTx-Transaktion des IBC-Pakets gepackt und an Kette B gesendet, die Blockheaderinformationen abfragt, wo sich packageTx befindet. Außerdem werden die Blockheaderinformationen in die IBCUpdate-Kette Tx gepackt und an die Kette B gesendet. Beachten Sie, dass der Relayer die Transaktionskosten für das IBC-Paket PostTx und die IBCUpdate-Kette Tx zahlt.

Nachdem Kette B die Transaktion IBCPacketPostTx empfangen hat, prüft sie zunächst, ob der Blockheader in IBCUpdateChainTx über den Validator in dieser Kette Teil von Kette A ist, und überprüft dann, ob der Merkle-Beweis der kettenübergreifenden Transaktion in IBCPacketPostTx mit dem Block übereinstimmt Header-Hash in IBCUpdateChainTx. Wenn alle Prüfungen bestanden sind, beginnt die B-Kette damit, verwandte Operationen auszuführen (für Kette B bedeutet dies, verwandte Assets usw. zu generieren).

Typ IBCRegisterChainTx struct {BlockchainGenesis}Typ BlockchainGenesis struct {ChainID-ZeichenfolgeGenesis-Zeichenfolge}

Typ IBCUpdateChainTx struct {Header tm.HeaderCommit tm.Commit// TODO: NextValidators}

Typ IBCPacketCreateTx struct {Paket}Typ Packet struct {SrcChainID-ZeichenfolgeDstChainID-ZeichenfolgeSequenz uint64Geben Sie string // redundant ein, da Type () eine Methode für Payload ist.Nutzlast Nutzlast}

Typ IBCPacketPostTx struct {FromChainID string // Die unmittelbare Quelle des Pakets, nicht immer Packet.SrcChainIDFromChainHeight uint64 // Die Blockhöhe, in der Packet festgeschrieben wurde, um Proof zu überprüfenPaketBeweis * merkle.IAVLProof // Merkle 证明}

Typ Plugin Schnittstelle {// Name dieses Plugins sollte kurz sein.Name () Zeichenfolge// Führen Sie eine Transaktion von ABCI DeliverTx ausRunTx (speichere KVStore, ctx CallContext, txBytes []Byte) (res abci.Result)// Andere ABCI-Message-HandlerSetOption (KVStore, Schlüssel, Wertzeichenfolge speichern) (Protokollzeichenfolge)InitChain (KVStore speichern, vals []* abci.Validator)BeginBlock (KVStore, Hash speichern) []Byte, Header * abci.Header)EndBlock (KVStore speichern, Höhe uint64) abci.ResponseEndBlock}

// ABCI :: DeliverTxfunc (app * BaseApp) DeliverTx (txBytes []Byte) (res abci.Result) {// Exec txSchalter tx: = tx. (Typ) {case * types.SendTx:// 执行 正常 交 交case * types.AppTx:// 执行 Plugin 中 的 交易plugin: = pgz.GetByName (tx.Name)res = plugin.RunTx (cache, ctx, tx.Data)Rückgabe resStandard:return abci.ErrBaseEncodingError.SetLog ("Unbekannter TX-Typ")}Rückgabe res}