Chaincode-Lebenszyklus
Der Chaincode-Lebenszyklus beschreibt den Prozess der Installation von Chaincode auf Peers und der Bereitstellung auf einem Kanal.
Der Chaincode-Lebenszyklus basiert auf den Funktionen der Hyperledger Fabric-Plattform, die eine dezentrale Governance von Chaincodes ermöglicht. Mehrere Organisationen können sich auf Chaincode-Parameter einigen, einschließlich der Chaincode-Bestätigungsrichtlinie, bevor ein Chaincode mit dem Ledger interagieren kann. Diese Funktionen werden in den neuen schnellen Deployment- und erweiterten Deployment-Optionen sowie in der REST-API implementiert. Weitere Informationen zum Lebenszyklus finden Sie unter Fabric chaincode Lifecycle in der Hyperledger Fabric-Dokumentation.
In der Regel verwenden Sie ein schnelles Deployment oder ein erweitertes Deployment in der Konsole, um einen installierten Chaincode bereitzustellen. Der Deployment-Prozess umfasst das Packen und Installieren des Chaincodes sowie das Genehmigen und Festschreiben der Chaincode-Definition. Sie können die REST-API auch verwenden, um die Genehmigungs- und Verpflichtungsvorgänge separat abzuschließen.
Chaincode verpacken und installieren
Wenn Sie Chaincode in Oracle Blockchain Platform installieren, wird der Chaincode in einem Package verpackt, installiert und eine Package-ID automatisch generiert. Die Paket-ID wird auf der Registerkarte Chaincodes der Konsole angezeigt.
Chaincode-Definition genehmigen
Bevor ein Chaincode in einem Kanal bereitgestellt werden kann, muss die Chaincodedefinition von genügend Organisationen genehmigt werden, um die LifecycleEndorsement-Policy des Kanals zu erfüllen. Mit der Standard-Policy LifecycleEndorsement in Oracle Blockchain Platform kann jede Organisation die Chaincode-Definition genehmigen (im Gegensatz zu einer Mehrheit der Organisationen). Die Chaincode-Definition enthält die folgenden Parameter, die für alle Organisationen identisch sein müssen: Chaincode Name, Version, Sequence, Endorsement Policy, Private Data Collection und Init-required. Eine Chaincodedefinition kann auch eine Package ID enthalten, die nicht für alle Organisationen identisch sein muss.
Nachdem eine Chaincode-Definition genehmigt wurde, kann eine Organisation Bestätigungen von Kollegen der genehmigenden Organisationen erfassen und dann die Chaincode-Definition im Kanal festschreiben.
Informationen zum Genehmigen einer Chaincode-Definition mit der REST-API finden Sie unter Chaincode-Definition in einem Kanal genehmigen.
Wenn Sie in der Konsole ein schnelles Deployment oder ein erweitertes Deployment verwenden, werden die Genehmigungs- und Commitmentschritte versucht.
Chaincode-Definition festschreiben
Informationen zum Festschreiben einer genehmigten Chaincode-Definition mit der REST-API finden Sie unter Caincode-Definition in einem Kanal festschreiben.
In der Konsole werden Chaincode-Definitionen angezeigt, die genehmigt, aber nicht festgeschrieben wurden, auf der Seite Bereitgestellte Chaincodes für den Kanal. Mit dem Menü Weitere Aktionen können Sie den genehmigten Chaincode festschreiben.
Chaincode-Lebenszyklus - Szenarios
| Scenario | Beschreibung |
|---|---|
| Kanal beitreten |
Normalerweise genehmigen Sie in der Konsole keine Chaincode-Definition, ohne sie dann festzuschreiben. Wenn Sie einem gemeinsamen Kanal beitreten, in dem eine Chaincode-Definition von einer anderen Organisation festgeschrieben wurde, wird die Chaincode-Definition auf der Seite Bereitgestellte Chaincodes für den Kanal als festgeschrieben, aber nicht genehmigt aufgeführt. Im Menü Weitere Aktionen können Sie die Chaincode-Definition genehmigen und auch eine Package-ID zuordnen. Sie müssen die Package-Definition nicht erneut festschreiben. |
| Bestätigungs-Policy aktualisieren |
Sie können die Bestätigungsrichtlinie in der Chaincode-Definition aktualisieren, ohne den Chaincode neu zu installieren. Verwenden Sie auf der Seite "Bereitgestellte Chaincodes" für den Kanal das Menü "Weitere Aktionen", um die Chaincode-Definition zu aktualisieren. Blenden Sie Endorsement Policy ein, und geben Sie eine neue Policy an. Klicken Sie dann auf Upgrade. |
| Definition ohne Installation genehmigen |
Wenn Sie eine Chaincode-Definition in einem Szenario mit mehreren Organisationen genehmigen möchten, ohne das Chaincode-Paket zu installieren, geben Sie keine Package-ID an. Sie bestätigen die Definition des Chaincodes, der für den Kanal festgeschrieben wird, aber der Chaincode ist nicht auf Peers in Ihrer Organisation installiert. Sie können den Chaincode nicht verwenden, um Transaktionen zu bestätigen oder das Buch abzufragen. |
| Uneinigkeit über Definitionen |
In einem Szenario mit mehreren Organisationen kann eine Organisation, die keine Chaincode-Definition genehmigt oder eine andere Chaincode-Definition genehmigt, den Chaincode nicht für ihre Peers ausführen. Wenn andere Organisationen genügend Bestätigungen erhalten, um die Definition für den Kanal festzuschreiben, können diese Organisationen den Chaincode verwenden. Transaktionen werden weiterhin den gleichgestellten Mitarbeitern aller Organisationen zum Buch hinzugefügt. Wenn Organisationen sich nicht auf eine Chaincode-Definition einigen und keine Organisationen genügend Bestätigungen erhalten, um die Definition für den Kanal festzuschreiben, kann die Definition nicht festgeschrieben werden, und daher kann der Chaincode nicht ausgeführt werden. |
| Mehrere Organisationen installieren verschiedene Packages |
Sie können eine andere Paket-ID angeben, wenn Sie eine Chaincode-Definition für einen Kanal mit mehreren Organisationen genehmigen. Wenn der Definitionsname und die Bestätigungs-Policy identisch sind, können Channel-Mitglieder Chaincode installieren, der für ihre Organisation spezifisch ist, jedoch Daten liest und in denselben Chaincode-Namespace schreibt. |
| Mehrere Chaincodes aus einem Paket erstellen |
Ebenso können Sie dasselbe Chaincode-Package mehrmals genehmigen und festschreiben, indem Sie für jede Definition einen anderen Namen angeben. Mehrere Instanzen des Chaincodes werden auf dem Kanal ausgeführt. Wenn Sie für jede Definition auch eine andere Bestätigungs-Policy angeben, unterliegt jede Chaincodeinstanz einer anderen Bestätigungs-Policy. |