Come eseguire transazioni di asset digitali con il calcolo a parti multiple e Confidential Space

1. Panoramica

Prima di iniziare, anche se non del tutto necessario, una conoscenza pratica delle seguenti funzionalità e concetti sarà utile in questo codelab.

• Cloud Storage, in particolare i bucket
• Compute Engine, in particolare Confidential VM
• Service account
• Container e repository remoti
• Federazione delle identità per i workload e condizioni degli attributi

Obiettivi didattici

Questo lab fornisce un'implementazione di riferimento per l'esecuzione della firma blockchain conforme a MPC utilizzando Confidential Space. Per illustrare i concetti, esamineremo uno scenario in cui la Società Primus vuole trasferire asset digitali alla Società Secundus. In questo scenario, la società Primus utilizza un modello conforme a MPC, il che significa che, anziché utilizzare singole chiavi private, utilizza frazioni di chiavi distribuite. Queste chiavi partizionate sono detenute da più parti, in questo caso Alice e Bob. Questo approccio offre alla Società Primus diversi vantaggi, tra cui un'esperienza utente semplificata, efficienza operativa e controllo sulle chiavi private.

Per spiegare gli aspetti fondamentali di questa procedura, illustreremo la configurazione tecnica e la procedura di approvazione e firma che avvia il trasferimento delle risorse digitali dalla Società Primus alla Società Secundus. Tieni presente che Bob e Alice, entrambi dipendenti della Società Primus, devono approvare la transazione.

Sebbene questa implementazione di riferimento dimostri le operazioni di firma, non copre tutti gli aspetti della gestione delle chiavi MPC. Ad esempio, non parliamo della generazione delle chiavi. Esistono inoltre approcci alternativi e complementari, come l'utilizzo di servizi non Google Cloud per generare firme collettive o l'utilizzo di cofirmatari per creare firme blockchain nei propri ambienti, che è un'architettura più decentralizzata. Ci auguriamo che questo lab ti ispiri a utilizzare approcci diversi all'MPC su Google Cloud.

Utilizzerai un semplice carico di lavoro che firma una transazione Ethereum in Spazio riservato utilizzando i materiali delle chiavi dei cofirmatari. La firma delle transazioni Ethereum è un processo mediante il quale un utente può autorizzare una transazione sulla blockchain di Ethereum. Per inviare una transazione Ethereum, devi firmarla con la tua chiave privata. In questo modo dimostri di essere il proprietario dell'account e autorizzi la transazione. La procedura di firma è la seguente:

1. Il mittente crea un oggetto transazione che specifica l'indirizzo del destinatario, la quantità di ETH da inviare e qualsiasi altro dato pertinente.
2. La chiave privata del mittente viene utilizzata per sottoporre ad hashing i dati della transazione.
3. L'hash viene poi firmato con la chiave privata.
4. La firma è allegata all'oggetto della transazione.
5. La transazione viene trasmessa alla rete Ethereum.

Quando un nodo della rete riceve una transazione, ne verifica la firma per assicurarsi che sia stata firmata dal proprietario dell'account. Se la firma è valida, il nodo aggiungerà la transazione alla blockchain.

Per iniziare, devi configurare le risorse Cloud necessarie. Poi esegui il carico di lavoro nello spazio riservato. Questo codelab ti guiderà attraverso i seguenti passaggi di alto livello:

• Come configurare le risorse Cloud necessarie per l'esecuzione di Spazio riservato
• Come autorizzare l'accesso alle risorse protette in base agli attributi di:
• Che cosa: il contenitore del carico di lavoro
• Dove: l'ambiente Confidential Space (l'immagine Confidential Space su Confidential VM)
• Chi: l'account che esegue il carico di lavoro
• Come eseguire il workload in una VM Confidential che esegue l'immagine VM Confidential Space

API obbligatorie

Per poter completare questa guida, devi abilitare le API seguenti nei progetti specificati.

Nome API	Titolo dell'API
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. Configurare le risorse cloud

Prima di iniziare

• Clona questo repository utilizzando il comando riportato di seguito per ottenere gli script richiesti utilizzati nell'ambito di questo codelab.

git clone https://github.com/GoogleCloudPlatform/confidential-space.git

• Modifica la directory per questo codelab.

cd confidential-space/codelabs/digital_asset_transaction_codelab/scripts

• Assicurati di aver impostato le variabili di ambiente del progetto richieste come mostrato di seguito. Per ulteriori informazioni sulla configurazione di un progetto Google Cloud, consulta questo codelab. Puoi fare riferimento a questa pagina per informazioni dettagliate su come recuperare l'ID progetto e su come si differenzia dal nome e dal numero di progetto. .

export PRIMUS_PROJECT_ID=<GCP project id>

• Attiva la fatturazione per i tuoi progetti.
• Abilita l'API Confidential Computing e le API seguenti per entrambi i progetti.

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

• Per impostare le variabili per i nomi delle risorse, puoi utilizzare il seguente comando. Tieni presente che questo sostituirà i nomi delle risorse specifici del tuo progetto Google Cloud per l'azienda A, ad esempio export PRIMUS_INPUT_STORAGE_BUCKET='primus-input-bucket'
• Per il progetto Google Cloud nella Società A puoi impostare le seguenti variabili:

$PRIMUS_INPUT_STORAGE_BUCKET	Il bucket che memorizza le chiavi criptate.
$PRIMUS_RESULT_STORAGE_BUCKET	Il bucket che memorizza il risultato della transazione MPC.
$PRIMUS_KEY	La chiave KMS utilizzata per criptare i dati archiviati in $PRIMUS_INPUT_STORAGE_BUCKET per Primus Bank.
$PRIMUS_KEYRING	Il portachiavi KMS che verrà utilizzato per creare la chiave di crittografia $PRIMUS_KEY per Primus Bank.
$PRIMUS_WIP_PROVIDER	Il provider del pool di identità del workload che include la condizione dell'attributo da utilizzare per i token firmati dal servizio di workload MPC.
$PRIMUS_SERVICEACCOUNT	L'account di servizio utilizzato da $PRIMUS_WORKLOAD_IDENTITY_POOL per accedere alle risorse protette. Questo account di servizio avrà l'autorizzazione per visualizzare le chiavi criptate archiviate nel bucket $PRIMUS_INPUT_STORAGE_BUCKET.
$PRIMUS_ARTIFACT_REPOSITORY	Il repository di elementi per l'archiviazione dell'immagine container del carico di lavoro.
$WORKLOAD_SERVICEACCOUNT	L'account di servizio che ha l'autorizzazione per accedere alla VM con accesso riservato che esegue il workload.
$WORKLOAD_CONTAINER	Il container Docker che esegue il carico di lavoro.
$WORKLOAD_IMAGE_NAME	Il nome dell'immagine del contenitore del workload.
$WORKLOAD_IMAGE_TAG	Il tag dell'immagine container del carico di lavoro.

• Esegui il seguente script per impostare i nomi delle variabili rimanenti su valori basati sull'ID progetto per i nomi delle risorse.

source config_env.sh

Configura le risorse Cloud

In questo passaggio, configurerai le risorse cloud necessarie per il calcolo multipartito. Per questo lab utilizzerai la seguente chiave privata: 0000000000000000000000000000000000000000000000000000000000000001

In un ambiente di produzione, dovrai generare la tua chiave privata. Tuttavia, ai fini di questo lab, suddivideremo questa chiave privata in due parti e ne criptaremo ciascuna. In uno scenario di produzione, le chiavi non devono mai essere archiviate in file di testo non criptato. La chiave privata può essere generata al di fuori di Google Cloud (o ignorata del tutto e sostituita con la creazione di uno shard della chiave MPC personalizzato) e poi criptata in modo che nessuno abbia accesso alla chiave privata o alle chiavi condivise. Ai fini di questo lab, utilizzeremo l'interfaccia a riga di comando gcloud.

Esegui il seguente script per configurare le risorse cloud richieste. Nell'ambito di questi passaggi verranno create le risorse indicate di seguito:

• Un bucket Cloud Storage ($PRIMUS_INPUT_STORAGE_BUCKET) per archiviare le chiavi private criptate.
• Un bucket Cloud Storage ($PRIMUS_RESULT_STORAGE_BUCKET) per archiviare il risultato della transazione di asset digitali.
• Una chiave di crittografia ($PRIMUS_KEY) e un portachiavi ($PRIMUS_KEYRING) in KMS per criptare le chiavi private condivise.
• Un pool di identità del workload ($PRIMUS_WORKLOAD_IDENTITY_POOL) per convalidare le rivendicazioni in base alle condizioni degli attributi configurate nel relativo fornitore.
• Un account di servizio ($PRIMUS_SERVICEACCOUNT) collegato al pool di identità del carico di lavoro ($PRIMUS_WORKLOAD_IDENTITY_POOL) sopra indicato con il seguente accesso IAM:
• roles/cloudkms.cryptoKeyDecrypter per decriptare i dati utilizzando la chiave KMS.
• objectViewer per leggere i dati dal bucket Cloud Storage.
• roles/iam.workloadIdentityUser per connettere questo account di servizio al pool di identità del workload.

./setup_resources.sh

3. Crea workload

Crea un account di servizio per il workload

Ora dovrai creare un account di servizio per il carico di lavoro con i ruoli e le autorizzazioni richiesti. Per farlo, esegui il seguente script, che creerà un account di servizio per il carico di lavoro della Società A. Questo account di servizio verrà utilizzato dalla VM che esegue il carico di lavoro.

L'account di servizio del carico di lavoro ($WORKLOAD_SERVICEACCOUNT) avrà i seguenti ruoli:

• confidentialcomputing.workloadUser per ottenere un token di attestazione
• logging.logWriter per scrivere i log in Cloud Logging.
• objectViewer per leggere i dati dal bucket Cloud Storage $PRIMUS_INPUT_STORAGE_BUCKET.
• objectUser per scrivere il risultato del carico di lavoro nel bucket Cloud Storage $PRIMUS_RESULT_STORAGE_BUCKET.

./create_workload_service_account.sh

Crea workload

Questo passaggio prevede la creazione di un'immagine Docker del carico di lavoro. Il workload in questo codelab è una semplice applicazione MPC Node.js che firma le transazioni digitali per il trasferimento di asset utilizzando le quote della chiave privata criptata. Qui è riportato il codice del progetto del carico di lavoro. Il progetto del carico di lavoro include i seguenti file.

package.json::questo file contiene l'elenco dei pacchetti da utilizzare per l'applicazione MPC del carico di lavoro. In questo caso, utilizziamo le librerie @google-cloud/kms, @google-cloud/storage, ethers e fast-crc32c. Qui è riportato il file package.json che utilizzeremo per questo codelab.

index.js::è un punto di ingresso dell'applicazione del carico di lavoro e specifica i comandi da eseguire all'avvio del container del carico di lavoro. Abbiamo incluso anche una transazione non firmata di esempio che in genere viene fornita da un'applicazione non attendibile che chiede agli utenti la firma. Questo file index.js importa anche le funzioni da mpc.js, che creeremo in seguito. Di seguito sono riportati i contenuti del file index.js, che puoi trovare anche qui.

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::è qui che avviene la firma della transazione. Importa le funzioni da kms-decrypt e credential-config, che esamineremo di seguito. Di seguito sono riportati i contenuti del file mpc.js, che puoi trovare anche qui.

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:questo file contiene il codice per la decrittografia utilizzando le chiavi gestite in KMS. Di seguito sono riportati i contenuti del file kms-decrypt.js, che puoi trovare anche qui.

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:il file memorizza i percorsi e i dettagli del pool di identità del carico di lavoro per la simulazione dell'identità dell'account di servizio. Qui è il file credential-config.js che utilizzeremo per questo codelab.

Dockerfile:infine, creeremo il nostro Dockerfile che verrà utilizzato per creare l'immagine Docker del carico di lavoro. definisce il Dockerfile come specificato qui.

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" ]

Nota:LABEL "tee.launch_policy.allow_cmd_override"="true" nel Dockerfile è un criterio di avvio impostato dall'autore dell'immagine. Consente all'operatore di eseguire l'override del CMD durante l'esecuzione del carico di lavoro. Per impostazione predefinita, allow_cmd_override è impostato su false. L'etichetta "tee.launch_policy.allow_env_override" indica a Confidential Space quali variabili di ambiente possono essere utilizzate dagli utenti dell'immagine .

Esegui il seguente script per creare un carico di lavoro in cui vengono eseguiti i seguenti passaggi:

• Crea Artifact Registry($PRIMUS_ARTIFACT_REPOSITORY) per archiviare l'immagine Docker del workload.
• Aggiorna il codice del carico di lavoro con i nomi delle risorse richieste. Qui è riportato il codice del carico di lavoro utilizzato per questo codelab.
• Crea il Dockerfile per la creazione di un'immagine Docker del codice del carico di lavoro. Puoi trovare il Dockerfile qui.
• Crea e pubblica l'immagine Docker in Artifact Registry ($PRIMUS_ARTIFACT_REPOSITORY) creato nel passaggio precedente.
• Concedi a $WORKLOAD_SERVICEACCOUNT l'autorizzazione di lettura per $PRIMUS_ARTIFACT_REPOSITORY. Questo è necessario affinché il container del carico di lavoro estragga l'immagine Docker del carico di lavoro da Artifact Registry.

./create_workload.sh

Crea il nodo blockchain

Nodo Ethereum Ganache

Prima di autorizzare il carico di lavoro, dobbiamo creare l'istanza Ethereum Ganache. La transazione firmata verrà inviata a questa istanza Ganache. Prendi nota dell'indirizzo IP di questa istanza. Dopo aver eseguito il comando seguente, potrebbe essere necessario inserire y per attivare l'API.

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. Autorizza ed esegui il carico di lavoro

Autorizza il workload

Nell'ambito di questo passaggio, configureremo il fornitore del pool di identità del workload nel pool di identità del workload ($PRIMUS_WORKLOAD_IDENTITY_POOL). Esistono condizioni degli attributi configurate per l'identità del workload, come mostrato di seguito. Una delle condizioni è convalidare che l'immagine del carico di lavoro venga estratta dal repository di elementi previsto.

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"

Esegui workload

Questa sezione spiega come eseguire il carico di lavoro su Confidential VM. A questo scopo, passeremo gli argomenti TEE richiesti utilizzando il flag dei metadati. Inoltre, imposteremo le variabili di ambiente per il container del carico di lavoro utilizzando il flag "tee-env-*". L'immagine ha le seguenti variabili:

• NODE_URL: l'URL del nodo Ethereum che elaborerà la transazione firmata.
• RESULTS_BUCKET: il bucket che memorizza il risultato della transazione mpc.
• KEY_BUCKET: il bucket che memorizza le chiavi criptate con mpc.
• PRIMUS_PROJECT_NUMBER: il numero del progetto utilizzato per il file di configurazione delle credenziali.
• PRIMUS_PROJECT_ID: l'ID progetto utilizzato per il file di configurazione delle credenziali. Il risultato dell'esecuzione del workload verrà pubblicato in $PRIMUS_RESULT_STORAGE_BUCKET.
• PRIMUS_WORKLOAD_IDENTITY_POOL: il pool di identità del workload utilizzato per convalidare i claim.
• PRIMUS_WIP_POROVIDER: il fornitore del pool di identità del workload che include le condizioni degli attributi da utilizzare per convalidare i token presentati dal workload.
• WORKLOAD_SERVICEACCOUNT: l'account di servizio del carico di lavoro.

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}"

Controlla i risultati di Cloud Storage

Puoi visualizzare la ricevuta della transazione in Cloud Storage. Potrebbero essere necessari alcuni minuti per l'avvio dello Spazio riservato e la visualizzazione dei risultati. Saprai che il contenitore è stato creato quando la VM è nello stato di arresto.

1. Vai alla pagina Browser Cloud Storage.
2. Fai clic su $PRIMUS_RESULT_STORAGE_BUCKET.
3. Fai clic sul file transaction_receipt.
4. Fai clic su Scarica per scaricare e visualizzare la risposta alla transazione.

In alternativa, puoi eseguire i seguenti comandi per visualizzare il risultato.

gcloud config set project $PRIMUS_PROJECT_ID

gsutil cat gs://$PRIMUS_RESULT_STORAGE_BUCKET/transaction_receipt

Nota: se i risultati non vengono visualizzati, puoi andare a $WORKLOAD_VM nella pagina della console Cloud Compute Engine e fare clic su "Porta seriale 1 (console)" per visualizzare i log.

Controlla la transazione blockchain di Ganache

Puoi anche visualizzare la transazione nel log della blockchain.

1. Vai alla pagina Cloud Compute Engine.
2. Fai clic su ${ETHEREUM_NODE} VM.
3. Fai clic su SSH per aprire la finestra SSH nel browser.
4. Nella finestra SSH, inserisci sudo docker ps per visualizzare il contenitore Ganache in esecuzione.
5. Trovare l'ID contenitore per trufflesuite/ganache:v7.7.3
6. Inserisci sudo docker logs CONTAINER_ID sostituendo CONTAINER_ID con l'ID di trufflesuite/ganache:v7.7.3.
7. Visualizza i log di Ganache e verifica che sia presente una transazione elencata nei log.

5. Esegui la pulizia

Qui è riportato lo script che può essere utilizzato per ripulire le risorse che abbiamo creato nell'ambito di questo codelab. Nell'ambito di questa operazione di pulizia, verranno eliminate le seguenti risorse:

• Bucket di archiviazione di input utilizzato per memorizzare le partizioni di chiavi criptate ($PRIMUS_INPUT_STORAGE_BUCKET).
• Chiave di crittografia ($PRIMUS_KEY).
• Account di servizio utilizzato per accedere alle risorse protette ($PRIMUS_SERVICEACCOUNT).
• Pool di identità del workload ($PRIMUS_WORKLOAD_IDENTITY_POOL).
• Service account del carico di lavoro ($WORKLOAD_SERVICEACCOUNT).
• Istanze Compute per i carichi di lavoro ($WORKLOAD_VM e $ETHEREUM_NODE).
• Bucket di archiviazione dei risultati utilizzato per archiviare il risultato della transazione.($PRIMUS_RESULT_STORAGE_BUCKET).
• Artifact Registry utilizzato per archiviare l'immagine del carico di lavoro ($PRIMUS_ARTIFACT_REPOSITORY).

./cleanup.sh

Se hai finito di esplorare, valuta la possibilità di eliminare il progetto.

• Vai alla console della piattaforma Cloud.
• Seleziona il progetto che vuoi arrestare, quindi fai clic su "Elimina" in alto. Il progetto viene pianificato per l'eliminazione.

Passaggi successivi

Dai un'occhiata ad alcuni di questi codelab simili…

• Dati condivisi protetti in uso con Confidential Space
• Codelab sull'immagine container firmata
• Analizzare i dati riservati con gli spazi riservati

Letture aggiuntive

• Ti senti isolato? Confidential Computing accorre in soccorso
• Confidential Computing su Google Cloud
• Confidential Space: il futuro della collaborazione incentrata sulla tutela della privacy
• In che modo Google e Intel rendono più sicuro il Confidential Computing
• Privacy e progresso: migliorare la sicurezza con il Confidential Computing di Google Cloud