So werden digitale Assets mit Multi-Party Computation und Confidential Space bearbeitet

So werden digitale Assets mit Multi-Party Computation und Confidential Space bearbeitet

Informationen zu diesem Codelab

subjectZuletzt aktualisiert: Jan. 9, 2025
account_circleVerfasst von Devon Yarbrough, Bertrand Portier, Chris Diya, Meetrajsinh Vala

1. Übersicht

Bevor wir beginnen, sollten Sie sich mit den folgenden Funktionen und Konzepten vertraut machen. Das ist zwar nicht unbedingt erforderlich, wird Ihnen aber in diesem Codelab helfen.

4670cd5427aa39a6.png

Lerninhalte

Dieses Lab enthält eine Referenzimplementierung für die MPC-konforme Blockchain-Signatur mit Confidential Space. Zur Veranschaulichung der Konzepte gehen wir ein Szenario durch, in dem Unternehmen 1 digitale Assets an Unternehmen 2 übertragen möchte. In diesem Szenario verwendet das Unternehmen Primus ein MPC-kompatibles Modell. Das bedeutet, dass anstelle einzelner privater Schlüssel verteilte Schlüsselfreigaben verwendet werden. Diese Schlüsselanteile werden von mehreren Parteien gehalten, in diesem Fall von Alice und Bob. Dieser Ansatz bietet dem Unternehmen Primus mehrere Vorteile, darunter eine vereinfachte Nutzererfahrung, Betriebseffizienz und Kontrolle über seine privaten Schlüssel.

Um die grundlegenden Aspekte dieses Prozesses zu erläutern, gehen wir ausführlich auf die technische Einrichtung ein und führen Sie durch den Genehmigungs- und Signaturprozess, der die Übertragung digitaler Assets von Unternehmen 1 an Unternehmen 2 initiiert. Beachten Sie, dass Bob und Alice, die beide Mitarbeiter von Primus sind, die Transaktion genehmigen müssen.

Diese Referenzimplementierung zeigt zwar Signaturvorgänge, deckt aber nicht alle Aspekte der MPC-Schlüsselverwaltung ab. So werden beispielsweise keine Informationen zur Schlüsselgenerierung behandelt. Darüber hinaus gibt es alternative und ergänzende Ansätze, z. B. die Verwendung von Diensten außerhalb von Google Cloud zum Generieren von Co-Signaturen oder die Erstellung von Blockchain-Signaturen durch Co-Unterzeichner in ihren eigenen Umgebungen, was eine dezentralere Architektur darstellt. Wir hoffen, dass dieses Lab Sie zu verschiedenen Ansätzen für die Multi-Party-Konnektivität in Google Cloud inspiriert.

Sie arbeiten mit einer einfachen Arbeitslast, die eine Ethereum-Transaktion in Confidential Space mit Co-Signaturschlüsselmaterialien signiert. Die Ethereum-Transaktionssignatur ist ein Prozess, mit dem ein Nutzer eine Transaktion in der Ethereum-Blockchain autorisieren kann. Wenn Sie eine Ethereum-Transaktion senden möchten, müssen Sie sie mit Ihrem privaten Schlüssel signieren. So beweisen Sie, dass Sie der Inhaber des Kontos sind und die Transaktion autorisieren. So läuft der Signaturvorgang ab:

  1. Der Absender erstellt ein Transaktionsobjekt, das die Empfängeradresse, die zu sendende ETH-Menge und alle anderen relevanten Daten angibt.
  2. Der private Schlüssel des Absenders wird zum Hashen der Transaktionsdaten verwendet.
  3. Der Hash wird dann mit dem privaten Schlüssel signiert.
  4. Die Signatur ist mit dem Transaktionsobjekt verknüpft.
  5. Die Transaktion wird an das Ethereum-Netzwerk gesendet.

Wenn ein Knoten im Netzwerk eine Transaktion empfängt, wird die Signatur überprüft, um sicherzustellen, dass sie vom Kontoinhaber unterzeichnet wurde. Wenn die Signatur gültig ist, fügt der Knoten die Transaktion der Blockchain hinzu.

Zuerst konfigurieren Sie die erforderlichen Cloud-Ressourcen. Anschließend führen Sie die Arbeitslast in Confidential Space aus. In diesem Codelab werden Sie durch die folgenden allgemeinen Schritte geführt:

  • Erforderliche Cloud-Ressourcen für den Betrieb von vertraulichen Gruppenbereichen konfigurieren
  • So autorisieren Sie den Zugriff auf geschützte Ressourcen basierend auf den Attributen von:
  • Was: Arbeitslastcontainer
  • Wo: in der Confidential Space-Umgebung (das Confidential Space-Image auf der Confidential VM)
  • Wer: das Konto, auf dem die Arbeitslast ausgeführt wird
  • Arbeitslast in einer Confidential VM ausführen, auf der das VM-Image für Confidential Space ausgeführt wird

Erforderliche APIs

Sie müssen die folgenden APIs in den angegebenen Projekten aktivieren, um diesen Leitfaden ausführen zu können.

API-Name

API-Titel

cloudkms.googleapis.com

Cloud KMS

compute.googleapis.com

Compute Engine

confidentialcomputing.googleapis.com

Confidential Computing

iamcredentials.googleapis.com

IAM

artifactregistry.googleapis.com

Artifact Registry

2. Cloud-Ressourcen einrichten

Hinweis

  • Klonen Sie dieses Repository mit dem folgenden Befehl, um die erforderlichen Scripts zu erhalten, die in diesem Codelab verwendet werden.
git clone https://github.com/GoogleCloudPlatform/confidential-space.git
  • Wechseln Sie in das Verzeichnis für dieses Codelab.
cd confidential-space/codelabs/digital_asset_transaction_codelab/scripts
  • Achten Sie darauf, dass Sie die erforderlichen Projektumgebungsvariablen wie unten gezeigt festgelegt haben. Weitere Informationen zum Einrichten eines GCP-Projekts finden Sie in diesem Codelab. In diesem Artikel finden Sie Details dazu, wie Sie die Projekt-ID abrufen und wie sie sich von Projektnamen und Projektnummer unterscheidet. .
export PRIMUS_PROJECT_ID=<GCP project id>
gcloud services enable \
   cloudapis.googleapis.com \
    cloudkms.googleapis.com \
    cloudresourcemanager.googleapis.com \
    cloudshell.googleapis.com \
    container.googleapis.com \
    containerregistry.googleapis.com \
    iam.googleapis.com \
    confidentialcomputing.googleapis.com
  • Mit dem folgenden Befehl können Sie die Variablen für die Ressourcennamen festlegen. Hinweis: Dadurch werden die für Ihr GCP-Projekt spezifischen Ressourcennamen für Unternehmen A überschrieben, z. B. export PRIMUS_INPUT_STORAGE_BUCKET='primus-input-bucket'
  • Für Ihr GCP-Projekt in Unternehmen A können die folgenden Variablen festgelegt werden:

$PRIMUS_INPUT_STORAGE_BUCKET

Der Bucket, in dem die verschlüsselten Schlüssel gespeichert werden.

$PRIMUS_RESULT_STORAGE_BUCKET

Der Bucket, in dem das MPC-Transaktionsergebnis gespeichert wird.

$PRIMUS_KEY

Der KMS-Schlüssel, der zum Verschlüsseln der Daten verwendet wird, die im Bucket $PRIMUS_INPUT_STORAGE_BUCKET für die Primus Bank gespeichert sind.

$PRIMUS_KEYRING

Der KMS-Schlüsselbund, mit dem der Verschlüsselungsschlüssel $PRIMUS_KEY für die Primus Bank erstellt wird.

$PRIMUS_WIP_PROVIDER

Der Workload Identity-Pool-Anbieter, der die Attributbedingung enthält, die für vom MPC-Arbeitslastdienst signierte Tokens verwendet werden soll.

$PRIMUS_SERVICEACCOUNT

Das Dienstkonto, das $PRIMUS_WORKLOAD_IDENTITY_POOL für den Zugriff auf die geschützten Ressourcen verwendet. Dieses Dienstkonto hat die Berechtigung, die verschlüsselten Schlüssel aufzurufen, die im Bucket $PRIMUS_INPUT_STORAGE_BUCKET gespeichert sind.

$PRIMUS_ARTIFACT_REPOSITORY

Das Artefakt-Repository zum Speichern des Arbeitslast-Container-Images.

$WORKLOAD_SERVICEACCOUNT

Das Dienstkonto, das auf die vertrauliche VM zugreifen darf, auf der die Arbeitslast ausgeführt wird.

$WORKLOAD_CONTAINER

Der Docker-Container, in dem die Arbeitslast ausgeführt wird.

$WORKLOAD_IMAGE_NAME

Der Name des Arbeitslast-Container-Images.

$WORKLOAD_IMAGE_TAG

Das Tag des Arbeitslastcontainer-Images.

  • Führen Sie das folgende Script aus, um die verbleibenden Variablennamen auf Werte basierend auf Ihrer Projekt-ID für Ressourcennamen festzulegen.
source config_env.sh

Cloud-Ressourcen einrichten

In diesem Schritt richten Sie die für die Multi-Party-Berechnung erforderlichen Cloud-Ressourcen ein. In diesem Lab verwenden Sie den folgenden privaten Schlüssel: 0000000000000000000000000000000000000000000000000000000000000001.

In einer Produktionsumgebung generieren Sie Ihren eigenen privaten Schlüssel. Für die Zwecke dieses Labs teilen wir diesen privaten Schlüssel jedoch in zwei Anteile auf und verschlüsseln jeden. In einem Produktionsszenario sollten Schlüssel niemals in Klartextdateien gespeichert werden. Stattdessen kann der private Schlüssel außerhalb von Google Cloud generiert (oder vollständig übersprungen und durch die benutzerdefinierte Erstellung von MPC-Schlüssel-Shards ersetzt) und dann verschlüsselt werden, sodass niemand Zugriff auf den privaten Schlüssel oder die Schlüsselanteile hat. In diesem Lab verwenden wir die Gcloud CLI.

Führen Sie das folgende Script aus, um die erforderlichen Cloud-Ressourcen einzurichten. Dabei werden die folgenden Ressourcen erstellt:

  • Einen Cloud Storage-Bucket ($PRIMUS_INPUT_STORAGE_BUCKET) zum Speichern der verschlüsselten privaten Schlüsselanteile.
  • Einen Cloud Storage-Bucket ($PRIMUS_RESULT_STORAGE_BUCKET) zum Speichern des Ergebnisses der Transaktion für digitale Assets.
  • Einen Verschlüsselungsschlüssel ($PRIMUS_KEY) und einen Schlüsselring ($PRIMUS_KEYRING) in KMS zum Verschlüsseln der privaten Schlüsselanteile.
  • Ein Workload Identity-Pool ($PRIMUS_WORKLOAD_IDENTITY_POOL), um Ansprüche anhand von Attributbedingungen zu validieren, die beim Anbieter konfiguriert wurden.
  • Ein Dienstkonto ($PRIMUS_SERVICEACCOUNT), das mit dem oben genannten Workload Identity Pool ($PRIMUS_WORKLOAD_IDENTITY_POOL) verknüpft ist, mit folgendem IAM-Zugriff:
  • roles/cloudkms.cryptoKeyDecrypter, um die Daten mit dem KMS-Schlüssel zu entschlüsseln.
  • objectViewer, um Daten aus dem Cloud Storage-Bucket zu lesen.
  • roles/iam.workloadIdentityUser, um dieses Dienstkonto mit dem Workload Identity-Pool zu verbinden.
./setup_resources.sh

3. Arbeitslast erstellen

Dienstkonto für Arbeitslast erstellen

Sie erstellen jetzt ein Dienstkonto für die Arbeitslast mit den erforderlichen Rollen und Berechtigungen. Führen Sie dazu das folgende Script aus, um ein Arbeitslastdienstkonto für Unternehmen A zu erstellen. Dieses Dienstkonto wird von der VM verwendet, auf der die Arbeitslast ausgeführt wird.

Das Workload-Dienstkonto ($WORKLOAD_SERVICEACCOUNT) hat die folgenden Rollen:

  • confidentialcomputing.workloadUser, um ein Attestierungstoken zu erhalten
  • logging.logWriter, um Protokolle in Cloud Logging zu schreiben.
  • objectViewer, um Daten aus dem Cloud Storage-Bucket $PRIMUS_INPUT_STORAGE_BUCKET zu lesen.
  • objectUser, um das Arbeitslastergebnis in den Cloud Storage-Bucket $PRIMUS_RESULT_STORAGE_BUCKET zu schreiben.
./create_workload_service_account.sh

Arbeitslast erstellen

In diesem Schritt wird ein Docker-Image für die Arbeitslast erstellt. Die Arbeitslast in diesem Codelab ist eine einfache Node.js-MPC-Anwendung, die digitale Transaktionen für die Übertragung von Assets mit verschlüsselten privaten Schlüsselanteilen signiert. Hier ist der Projektcode der Arbeitslast. Das Arbeitslastprojekt enthält die folgenden Dateien.

package.json::Diese Datei enthält die Liste der Pakete, die für die MPC-Anwendung der Arbeitslast verwendet werden sollen. In diesem Fall verwenden wir die Bibliotheken @google-cloud/kms, @google-cloud/storage, ethers und fast-crc32c. Hier ist die package.json-Datei, die wir für dieses Codelab verwenden.

index.js::Dies ist der Einstiegspunkt der Arbeitslastanwendung. Hier wird angegeben, welche Befehle beim Start des Arbeitslastcontainers ausgeführt werden sollen. Außerdem haben wir eine Beispieltransaktion ohne Signatur hinzugefügt, die normalerweise von einer nicht vertrauenswürdigen Anwendung bereitgestellt wird, die Nutzer um ihre Unterschrift bittet. Diese index.js-Datei importiert auch Funktionen aus mpc.js, die wir als Nächstes erstellen. Unten sehen Sie den Inhalt der index.js-Datei. Sie können ihn auch hier herunterladen.

import {signTransaction, submitTransaction, uploadFromMemory} from './mpc.js';

const signAndSubmitTransaction = async () => {
 
try {
   
// Create the unsigned transaction object
   
const unsignedTransaction = {
     
nonce: 0,
     
gasLimit: 21000,
     
gasPrice: '0x09184e72a000',
     
to: '0x0000000000000000000000000000000000000000',
     
value: '0x00',
     
data: '0x',
   
};

   
// Sign the transaction
   
const signedTransaction = await signTransaction(unsignedTransaction);

   
// Submit the transaction to Ganache
   
const transaction = await submitTransaction(signedTransaction);

   
// Write the transaction receipt
   
uploadFromMemory(transaction);

   
return transaction;
 
} catch (e) {
   
console.log(e);
   
uploadFromMemory(e);
 
}
};

await signAndSubmitTransaction();

mpc.js::Hier findet die Transaktionssignatur statt. Es importiert Funktionen aus „kms-decrypt“ und „credential-config“, die wir als Nächstes behandeln. Unten findest du den Inhalt der Datei „mpc.js“. Du kannst ihn auch hier herunterladen.

import {Storage} from '@google-cloud/storage';
import {ethers} from 'ethers';

import {credentialConfig} from './credential-config.js';
import {decryptSymmetric} from './kms-decrypt.js';

const providers = ethers.providers;
const Wallet = ethers.Wallet;

// The ID of the GCS bucket holding the encrypted keys
const bucketName = process.env.KEY_BUCKET;

// Name of the encrypted key files.
const encryptedKeyFile1 = 'alice_encrypted_key_share';
const encryptedKeyFile2 = 'bob_encrypted_key_share';

// Create a new storage client with the credentials
const storageWithCreds = new Storage({
 
credentials: credentialConfig,
});

// Create a new storage client without the credentials
const storage = new Storage();

const downloadIntoMemory = async (keyFile) => {
 
// Downloads the file into a buffer in memory.
 
const contents =
     
await storageWithCreds.bucket(bucketName).file(keyFile).download();

 
return contents;
};

const provider =
   
new providers.JsonRpcProvider(`http://${process.env.NODE_URL}:80`);

export const signTransaction = async (unsignedTransaction) => {
 
/* Check if Alice and Bob have both approved the transaction
 
For this example, we're checking if their encrypted keys are available. */
 
const encryptedKey1 =
     
await downloadIntoMemory(encryptedKeyFile1).catch(console.error);
 
const encryptedKey2 =
     
await downloadIntoMemory(encryptedKeyFile2).catch(console.error);

 
// For each key share, make a call to KMS to decrypt the key
 
const privateKeyshare1 = await decryptSymmetric(encryptedKey1[0]);
 
const privateKeyshare2 = await decryptSymmetric(encryptedKey2[0]);

 
/* Perform the MPC calculations
 
In this example, we're combining the private key shares
 
Alternatively, you could import your mpc calculations here */
 
const wallet = new Wallet(privateKeyshare1 + privateKeyshare2);

 
// Sign the transaction
 
const signedTransaction = await wallet.signTransaction(unsignedTransaction);

 
return signedTransaction;
};

export const submitTransaction = async (signedTransaction) => {
 
// This can now be sent to Ganache
 
const hash = await provider.sendTransaction(signedTransaction);
 
return hash;
};

export const uploadFromMemory = async (contents) => {
 
// Upload the results to the bucket without service account impersonation
 
await storage.bucket(process.env.RESULTS_BUCKET)
     
.file('transaction_receipt_' + Date.now())
     
.save(JSON.stringify(contents));
};

kms-decrypt.js:Diese Datei enthält den Code für die Entschlüsselung mit Schlüsseln, die in KMS verwaltet werden. Unten finden Sie den Inhalt der Datei „kms-decrypt.js“. Sie können ihn auch hier herunterladen.

import {KeyManagementServiceClient} from '@google-cloud/kms';
import crc32c from 'fast-crc32c';

import {credentialConfig} from './credential-config.js';

const projectId = process.env.PRIMUS_PROJECT_ID;
const locationId = process.env.PRIMUS_LOCATION;
const keyRingId = process.env.PRIMUS_ENC_KEYRING;
const keyId = process.env.PRIMUS_ENC_KEY;

// Instantiates a client
const client = new KeyManagementServiceClient({
 
credentials: credentialConfig,
});

// Build the key name
const keyName = client.cryptoKeyPath(projectId, locationId, keyRingId, keyId);

export const decryptSymmetric = async (ciphertext) => {
 
const ciphertextCrc32c = crc32c.calculate(ciphertext);
 
const [decryptResponse] = await client.decrypt({
   
name: keyName,
   
ciphertext,
   
ciphertextCrc32c: {
     
value: ciphertextCrc32c,
   
},
 
});

 
// Optional, but recommended: perform integrity verification on
 
// decryptResponse. For more details on ensuring E2E in-transit integrity to
 
// and from Cloud KMS visit:
 
// https://cloud.google.com/kms/docs/data-integrity-guidelines
 
if (crc32c.calculate(decryptResponse.plaintext) !==
     
Number(decryptResponse.plaintextCrc32c.value)) {
   
throw new Error('Decrypt: response corrupted in-transit');
 
}

 
const plaintext = decryptResponse.plaintext.toString();

 
return plaintext;
};

credential-config.js:In dieser Datei werden die Pfade zum Workload Identity-Pool und Details zur Identitätsübernahme des Dienstkontos gespeichert. Hier ist die Datei „credential-config.js“, die wir für dieses Codelab verwenden.

Dockerfile:Zum Schluss erstellen wir das Dockerfile, mit dem das Docker-Image für die Arbeitslast erstellt wird. Das Dockerfile wird wie hier beschrieben definiert.

FROM node:16.18.0

ENV NODE_ENV=production

WORKDIR /app

COPY ["package.json", "package-lock.json*", "./"]

RUN npm install --production

COPY . .

LABEL "tee.launch_policy.allow_cmd_override"="true"
LABEL "tee.launch_policy.allow_env_override"="NODE_URL,RESULTS_BUCKET,KEY_BUCKET,PRIMUS_PROJECT_NUMBER,PRIMUS_PROJECT_ID,PRIMUS_WORKLOAD_IDENTITY_POOL,PRIMUS_WIP_PROVIDER,PRIMUS_SERVICEACCOUNT,PRIMUS_ENC_KEYRING,PRIMUS_ENC_KEY"

CMD [ "node", "index.js" ]

Hinweis:LABEL „tee.launch_policy.allow_cmd_override“=“true“ im Dockerfile ist eine vom Image-Autor festgelegte Startrichtlinie. Damit kann der Operator die CMD bei der Ausführung der Arbeitslast überschreiben. Standardmäßig ist „allow_cmd_override“ auf „false“ gesetzt. Das LABEL „tee.launch_policy.allow_env_override“ gibt an, welche Umgebungsvariablen Nutzer von Images verwenden können .

Führen Sie das folgende Script aus, um eine Arbeitslast zu erstellen, in der die folgenden Schritte ausgeführt werden:

  • Erstellen Sie eine Artifact Registry($PRIMUS_ARTIFACT_REPOSITORY), um das Docker-Image der Arbeitslast zu speichern.
  • Aktualisieren Sie den Arbeitslastcode mit den Namen der erforderlichen Ressourcen. Hier finden Sie den Code für die Arbeitslast, der in diesem Codelab verwendet wird.
  • Erstellen Sie ein Dockerfile, um ein Docker-Image des Arbeitslastcodes zu erstellen. Das Dockerfile finden Sie hier.
  • Erstellen Sie das Docker-Image und veröffentlichen Sie es in der im vorherigen Schritt erstellten Artifact Registry ($PRIMUS_ARTIFACT_REPOSITORY).
  • Gewähren Sie $WORKLOAD_SERVICEACCOUNT die Leseberechtigung für $PRIMUS_ARTIFACT_REPOSITORY. Dies ist erforderlich, damit der Arbeitslastcontainer das Docker-Image der Arbeitslast aus der Artifact Registry abrufen kann.
./create_workload.sh

Blockchain-Knoten erstellen

Ganache-Ethereum-Knoten

Bevor wir die Arbeitslast autorisieren, müssen wir die Ethereum-Ganache-Instanz erstellen. Die signierte Transaktion wird an diese Ganache-Instanz gesendet. Notieren Sie sich die IP-Adresse dieser Instanz. Nachdem Sie den folgenden Befehl ausgeführt haben, müssen Sie möglicherweise y eingeben, um die API zu aktivieren.

gcloud compute instances create-with-container ${ETHEREUM_NODE} \
  --zone=${PRIMUS_PROJECT_ZONE} \
  --tags=http-server \
  --project=${PRIMUS_PROJECT_ID} \
  --shielded-secure-boot \
  --shielded-vtpm \
  --shielded-integrity-monitoring \
  --container-image=docker.io/trufflesuite/ganache:v7.7.3 \
--container-arg=--wallet.accounts=\"0x0000000000000000000000000000000000000000000000000000000000000001,0x21E19E0C9BAB2400000\" \
  --container-arg=--port=80

4. Arbeitslast autorisieren und ausführen

Arbeitslast autorisieren

In diesem Schritt richten wir den Workload Identity-Poolanbieter unter dem Workload Identity-Pool ($PRIMUS_WORKLOAD_IDENTITY_POOL) ein. Für die Workload-Identität sind Attributebedingungen konfiguriert, wie unten dargestellt. Eine der Bedingungen besteht darin, zu prüfen, ob das Arbeitslast-Image aus dem erwarteten Artefakt-Repository abgerufen wird.

gcloud config set project $PRIMUS_PROJECT_ID
gcloud iam workload-identity-pools providers create-oidc ${PRIMUS_WIP_PROVIDER} \
 --location="${PRIMUS_PROJECT_LOCATION}" \
 --workload-identity-pool="$PRIMUS_WORKLOAD_IDENTITY_POOL" \
 --issuer-uri="https://confidentialcomputing.googleapis.com/" \
 --allowed-audiences="https://sts.googleapis.com" \
 --attribute-mapping="google.subject='assertion.sub'" \
 --attribute-condition="assertion.swname == 'CONFIDENTIAL_SPACE' && 'STABLE' in assertion.submods.confidential_space.support_attributes && assertion.submods.container.image_reference == '${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/$PRIMUS_PROJECT_ID/$PRIMUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG' && '$WORKLOAD_SERVICEACCOUNT@$PRIMUS_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts"

Arbeitslast ausführen

In diesem Abschnitt wird erläutert, wie Sie die Arbeitslast auf einer Confidential VM ausführen. Dazu übergeben wir die erforderlichen TEE-Argumente mit dem Metadaten-Flag. Außerdem legen wir mit dem Flag „tee-env-*“ Umgebungsvariablen für den Workload-Container fest. Das Bild hat die folgenden Variablen:

  • NODE_URL: Die URL des Ethereum-Knotens, der die signierte Transaktion verarbeitet.
  • RESULTS_BUCKET: Der Bucket, in dem das mpc-Transaktionsergebnis gespeichert wird.
  • KEY_BUCKET: Der Bucket, in dem die mit mpc verschlüsselten Schlüssel gespeichert werden.
  • PRIMUS_PROJECT_NUMBER: Die Projektnummer, die für die Anmeldedatenkonfigurationsdatei verwendet wird.
  • PRIMUS_PROJECT_ID: Die Projekt-ID, die für die Anmeldedatenkonfigurationsdatei verwendet wird. Das Ergebnis der Workload-Ausführung wird in $PRIMUS_RESULT_STORAGE_BUCKET veröffentlicht.
  • PRIMUS_WORKLOAD_IDENTITY_POOL: Der Workload Identity-Pool, der zum Validieren von Ansprüchen verwendet wird.
  • PRIMUS_WIP_POROVIDER: Der Anbieter des Workload Identity-Pools, der die Attributbedingungen enthält, die für die Validierung von vom Workload präsentierten Tokens verwendet werden.
  • WORKLOAD_SERVICEACCOUNT: Das Dienstkonto der Arbeitslast.
gcloud compute instances create $WORKLOAD_VM \
 --confidential-compute-type=SEV \
 --shielded-secure-boot \
 --maintenance-policy=TERMINATE \
 --scopes=cloud-platform \
 --zone=${PRIMUS_PROJECT_ZONE} \
 --project=${PRIMUS_PROJECT_ID} \
 --image-project=confidential-space-images \
 --image-family=confidential-space \
 --service-account=$WORKLOAD_SERVICEACCOUNT@$PRIMUS_PROJECT_ID.iam.gserviceaccount.com \
 --metadata "^~^tee-image-reference=${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/$PRIMUS_PROJECT_ID/$PRIMUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG~tee-restart-policy=Never~tee-env-NODE_URL=$(gcloud compute instances describe ${ETHEREUM_NODE} --format='get(networkInterfaces[0].networkIP)' --zone=${PRIMUS_PROJECT_ZONE})~tee-env-RESULTS_BUCKET=$PRIMUS_RESULT_STORAGE_BUCKET~tee-env-KEY_BUCKET=$PRIMUS_INPUT_STORAGE_BUCKET~tee-env-PRIMUS_PROJECT_ID=$PRIMUS_PROJECT_ID~tee-env-PRIMUS_PROJECT_NUMBER=$(gcloud projects describe $PRIMUS_PROJECT_ID --format="value(projectNumber)")~tee-env-PRIMUS_WORKLOAD_IDENTITY_POOL=$PRIMUS_WORKLOAD_IDENTITY_POOL~tee-env-PRIMUS_PROJECT_LOCATION=${PRIMUS_PROJECT_LOCATION}~tee-env-PRIMUS_WIP_PROVIDER=$PRIMUS_WIP_PROVIDER~tee-env-PRIMUS_SERVICEACCOUNT=$PRIMUS_SERVICEACCOUNT~tee-env-PRIMUS_KEY=${PRIMUS_KEY}~tee-env-PRIMUS_KEYRING=${PRIMUS_KEYRING}"

Cloud Storage-Ergebnisse prüfen

Sie können den Transaktionsbeleg in Cloud Storage aufrufen. Es kann einige Minuten dauern, bis der vertrauliche Bereich gestartet ist und Ergebnisse angezeigt werden. Sie erkennen, dass der Container fertig ist, wenn die VM den Status „Gestoppt“ hat.

  1. Rufen Sie die Seite Cloud Storage-Browser auf.
  2. Klicken Sie auf $PRIMUS_RESULT_STORAGE_BUCKET.
  3. Klicken Sie auf die Datei transaction_receipt.
  4. Klicken Sie auf „Herunterladen“, um die Transaktionsantwort herunterzuladen und anzusehen.

Alternativ können Sie die folgenden Befehle ausführen, um das Ergebnis aufzurufen.

gcloud config set project $PRIMUS_PROJECT_ID
gsutil cat gs://$PRIMUS_RESULT_STORAGE_BUCKET/transaction_receipt

Hinweis:Wenn keine Ergebnisse angezeigt werden, rufen Sie in der Cloud Console auf der Seite „Compute Engine“ die VM $WORKLOAD_VM auf und klicken Sie auf „Seriellport 1 (Konsole)“, um die Protokolle aufzurufen.

Ganache-Blockchain-Transaktion prüfen

Sie können die Transaktion auch im Blockchain-Log aufrufen.

  1. Rufen Sie die Seite Cloud Compute Engine auf.
  2. Klicken Sie auf ${ETHEREUM_NODE} VM.
  3. Klicken Sie auf SSH, um das SSH-Browserfenster zu öffnen.
  4. Geben Sie im SSH-Fenster sudo docker ps ein, um den laufenden Ganache-Container aufzurufen.
  5. Container-ID für trufflesuite/ganache:v7.7.3 ermitteln
  6. Geben Sie sudo docker logs CONTAINER_ID ein und ersetzen Sie CONTAINER_ID durch die ID für trufflesuite/ganache:v7.7.3.
  7. Rufen Sie die Protokolle für Ganache auf und prüfen Sie, ob eine Transaktion in den Protokollen aufgeführt ist.

5. Bereinigen

Hier finden Sie das Script, mit dem Sie die im Rahmen dieses Codelabs erstellten Ressourcen bereinigen können. Im Rahmen dieser Bereinigung werden die folgenden Ressourcen gelöscht:

  • Eingabespeicher-Bucket zum Speichern verschlüsselter Schlüsselanteile ($PRIMUS_INPUT_STORAGE_BUCKET).
  • Verschlüsselungsschlüssel ($PRIMUS_KEY)
  • Dienstkonto, das für den Zugriff auf geschützte Ressourcen verwendet wird ($PRIMUS_SERVICEACCOUNT).
  • Workload Identity-Pool ($PRIMUS_WORKLOAD_IDENTITY_POOL)
  • Arbeitslastdienstkonto ($WORKLOAD_SERVICEACCOUNT)
  • Arbeitslast-Compute-Instanzen ($WORKLOAD_VM und $ETHEREUM_NODE)
  • Bucket zum Speichern des Transaktionsergebnisses ($PRIMUS_RESULT_STORAGE_BUCKET).
  • Artifact Registry, die zum Speichern des Workload-Images ($PRIMUS_ARTIFACT_REPOSITORY) verwendet wird.
./cleanup.sh

Wenn Sie mit der explorativen Datenanalyse fertig sind, sollten Sie Ihr Projekt löschen.

  • Rufen Sie die Cloud Platform Console auf.
  • Wählen Sie das Projekt aus, das Sie beenden möchten, und klicken Sie oben auf „Löschen“. Dadurch wird das Projekt zum Löschen geplant.

Was liegt als Nächstes an?

Sehen Sie sich diese ähnlichen Codelabs an:

Weitere Informationen