Evaluasi kebijakan transaksi

Pratinjau

Produk ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum dari Persyaratan Khusus Layanan. Produk pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Sebelum Multi-party Compute menandatangani transaksi, transaksi tersebut akan dievaluasi berdasarkan kebijakan transaksi di instance Anda. Dokumen ini menjelaskan kebijakan mana yang dievaluasi, bagaimana kebijakan bergerak melalui siklus prosesnya, apa yang dapat diperiksa oleh kebijakan, dan mengapa transaksi ditolak.

Cara transaksi dievaluasi

Kebijakan transaksi adalah satu pernyataan Cedar permit atau forbid. Saat Penanda Tangan memanggil CreateTransaction, instance akan mendekode transaksi yang tidak ditandatangani di Transaction.payload dengan parser untuk Transaction.schema, dan mengevaluasi setiap kebijakan yang diterapkan terhadap transaksi sebelum pembagian kunci digunakan. Kebijakan diterapkan saat statusnya adalah ACTIVE atau PENDING_DISABLED. Untuk mengetahui informasi selengkapnya, lihat Siklus proses kebijakan.

Keputusan ini mengikuti tiga aturan:

1. Tolak secara default. Transaksi hanya diizinkan jika setidaknya satu kebijakan permit cocok dengannya. Tanpa kebijakan yang diterapkan, setiap transaksi akan ditolak.
2. Forbid wins. Jika ada kebijakan forbid yang cocok, transaksi akan ditolak, meskipun kebijakan permit juga cocok.
3. Kebijakan yang gagal dievaluasi tidak cocok. Misalnya, kebijakan yang membaca atribut konteks opsional yang tidak dimiliki transaksi akan gagal dievaluasi. Instance akan mencatat error, melewati kebijakan tersebut, dan memutuskan dengan kebijakan lain yang diterapkan. Hal ini juga berlaku untuk kebijakan forbid, jadi tulis kebijakan forbid yang tidak akan gagal jika ada atribut yang tidak ada. Sebagai contoh, lihat Skenario 8 dan Skenario 9.

Transaksi yang berisi beberapa transfer, seperti transaksi Solana dengan beberapa petunjuk transfer, dievaluasi sekali untuk setiap transfer. Transaksi hanya diizinkan jika setiap transfer diizinkan. Jika ada transfer yang ditolak atau tidak dapat didekode, seluruh transaksi akan ditolak.

Setiap evaluasi, izin, atau penolakan, menghasilkan data evaluasi yang ditampilkan pada transaksi di Transaction.policyEvaluationRecord.

Keputusan ini mengontrol apakah instance dapat menandatangani transaksi tanpa menunggu penanda tangan lainnya:

• PERMIT: jika permintaan CreateTransaction sudah membawa cukup otorisasi penanda tangan untuk memenuhi kebijakan kunci KeyRing, transaksi akan langsung berpindah ke SIGNING. Jika tidak, transaksi akan dibuat di PENDING_AUTHORIZATION dan menunggu penanda tangan lainnya.
• DENY: instance tidak menandatangani transaksi secara otomatis. Transaksi dibuat di PENDING_AUTHORIZATION dengan policyEvaluationRecord.decision ditetapkan ke DENY. Penanda tangan dapat meninjau data evaluasi dan menolak transaksi (RecordSignerDecision dengan DENY) atau tetap mengizinkannya (AUTHORIZE). Transaksi hanya ditandatangani jika cukup banyak penanda tangan yang mengizinkannya untuk memenuhi kebijakan kunci.

Kebijakan transaksi adalah pengaman pada penandatanganan otomatis, bukan pemblokiran pada penanda tangan: penanda tangan dapat mengizinkan transaksi yang ditolak oleh kebijakan. PolicyEvaluationRecord asli tetap dilampirkan ke transaksi untuk audit.

Siklus proses kebijakan

Kebijakan transaksi tidak dapat diubah. TransactionPolicy tidak memiliki metode update, dan rule-nya tidak dapat diubah. Untuk mengubah aturan, nonaktifkan kebijakan dengan DisableTransactionPolicy dan buat kebijakan baru dengan CreateTransactionPolicy.

Mengaktifkan atau menonaktifkan kebijakan memerlukan persetujuan dari kuorum Penulis Kebijakan (Pengguna dengan peran POLICY_AUTHOR aktif di User.roleStatuses). Setiap Penulis Kebijakan menandatangani TransactionPolicySigningPayload yang menyebutkan kebijakan (atau, untuk CreateTransactionPolicy, instance), tindakan (ACTIVATE atau DISABLE), dan rule.cedarDocument. Permintaan yang mengusulkan perubahan dihitung sebagai persetujuan pertama. Penulis Kebijakan Lainnya menyetujui dengan ApproveTransactionPolicy. Jumlah persetujuan yang diperlukan ada di activationInfo.requiredApprovals dan deactivationInfo.requiredApprovals. Jika instance hanya memerlukan satu persetujuan, perubahan akan langsung diterapkan.

Tabel berikut menjelaskan setiap status kebijakan dan apakah kebijakan dalam status tersebut diterapkan:

Negara bagian/Provinsi	Arti	Diterapkan?
PENDING_ACTIVE	Kebijakan telah diusulkan dan menunggu persetujuan Penulis Kebijakan.	Tidak
ACTIVE	Kebijakan ini memiliki activationInfo.requiredApprovals persetujuan.	Ya
PENDING_DISABLED	Penulis Kebijakan meminta untuk menonaktifkan kebijakan, dan permintaan tersebut sedang menunggu persetujuan.	Ya, hingga permintaan memiliki deactivationInfo.requiredApprovals persetujuan
DISABLED	Kebijakan dinonaktifkan, atau ditarik sebelum menjadi aktif. Kebijakan yang dinonaktifkan disimpan untuk audit.	Tidak

Kebijakan berpindah melalui status ini dalam satu arah:

• PENDING_ACTIVE hingga ACTIVE: aktivasi memiliki cukup persetujuan.
• PENDING_ACTIVE hingga DISABLED: Penulis Kebijakan menarik kebijakan dengan DisableTransactionPolicy sebelum kebijakan tersebut aktif.
• ACTIVE ke PENDING_DISABLED: Penulis Kebijakan memanggil DisableTransactionPolicy.
• PENDING_DISABLED hingga DISABLED: permintaan penonaktifan memiliki persetujuan yang cukup.

Kebijakan memasuki setiap status tertunda maksimal satu kali. Kebijakan yang dinonaktifkan tidak dapat diaktifkan lagi; buat kebijakan baru.

Untuk mengetahui siapa yang dapat memanggil metode ini, lihat Peran pengguna.

Versi set kebijakan

Set kebijakan adalah kumpulan kebijakan yang diterapkan (ACTIVE atau PENDING_DISABLED) pada suatu waktu. Setiap kali aktivasi atau penonaktifan selesai, instance akan memberikan nomor berikutnya dalam penghitung untuk instance tersebut, dan mencatatnya di activationInfo.transitionSequence atau deactivationInfo.transitionSequence. Nomor tersebut adalah versi set kebijakan yang dihasilkan oleh transisi.

Tabel berikut menunjukkan cara versi set kebijakan berubah selama urutan peristiwa:

Acara	Urutan transisi	Kebijakan yang diterapkan
Kebijakan A diaktifkan.	A: activationInfo.transitionSequence = 1	A
Kebijakan B diaktifkan.	B: activationInfo.transitionSequence = 2	A, B
Kebijakan C diusulkan (PENDING_ACTIVE), lalu ditarik.	Tidak ada	A, B
Permintaan penonaktifan untuk kebijakan A disetujui.	A: deactivationInfo.transitionSequence = 3	B

Membatalkan kebijakan PENDING_ACTIVE tidak akan pernah mengubah kumpulan kebijakan yang diterapkan, sehingga tidak mendapatkan urutan transisi dan tidak mengubah versi kumpulan kebijakan. Saat transisi menunggu persetujuan, transitionSequence-nya tidak ditetapkan.

Setiap evaluasi membaca kebijakan, KeyList, dan kunci pada createTime transaksi, dan mencatat urutan transisi tertinggi yang telah selesai pada waktu tersebut di policyEvaluationRecord.policySetVersion. Jika dua evaluasi memiliki versi set kebijakan yang sama, berarti keduanya menggunakan kebijakan yang sama.

Permintaan Cedar

Permintaan Cedar memiliki akun utama, tindakan, resource, dan konteks. Misalnya:

permit (
  principal == User::"[e-mail]",
  action == Action::"buy_transaction",
  resource == Resource::"transaction_management"
)
when {
  context.principal_keyring == "institutional-treasury" &&
  context has fiat_amount && context.fiat_amount <= 10000
};

Cara Pengguna dipetakan ke akun utama Cedar

Principal adalah inisiator transaksi: Pengguna yang principal-nya cocok dengan identitas yang diautentikasi dari pemanggil CreateTransaction. Pengguna tersebut harus memiliki peran SIGNER yang aktif. Di Cedar, akun utama adalah entity User yang ID-nya adalah kolom principal Pengguna, misalnya User::"[e-mail]".

Instance tidak meneruskan data entity apa pun ke Cedar. Entity User tidak memiliki atribut dan induk, sehingga:

• principal == User::"[e-mail]" mencocokkan transaksi yang dimulai Alice.
• principal in Team::"treasury" tidak pernah cocok. Untuk membatasi siapa yang dapat menandatangani dengan kunci, gunakan kebijakan kunci KeyRing. Untuk mencakup aturan ke grup kunci, centang context.principal_keyring.
• Aturan yang membaca atribut principal, seperti principal.team, gagal dievaluasi.

principal Pengguna tidak dapat diubah, sehingga aturan yang memberi nama akun utama akan terus merujuk ke identitas yang sama.

Tindakan dan resource

• action: nilai Transaction.action dalam permintaan CreateTransaction, yang diformat sebagai entity Action Cedar. CreateTransaction menerima tindakan berikut:

  Tindakan	Digunakan untuk
  Action::"buy_transaction"	Transaksi yang mengakuisisi aset.
  Action::"sell_transaction"	Transaksi yang menghapus aset.
  Action::"internal_transfer_transaction"	Transfer aset, seperti pembayaran atau pemindahan antar-kunci.

  Inisiator memilih tindakan; Multi-party Compute tidak menyimpulkannya dari payload. Aturan dapat mencocokkan satu tindakan (action == Action::"buy_transaction"), daftar tindakan (action in [Action::"buy_transaction", Action::"sell_transaction"]), atau membiarkan action tidak dibatasi untuk mencocokkan setiap tindakan.

• resource: selalu Resource::"transaction_management" untuk evaluasi transaksi. Aturan dapat memeriksa resource == Resource::"transaction_management" atau membiarkan resource tidak dibatasi.

Atribut konteks

Konteks menyimpan atribut yang diperiksa oleh kebijakan. Mereka berasal dari dua tempat:

• Payload transaksi dan kunci penandatanganan. Instance akan mendekode Transaction.payload dan menambahkan ID kunci penandatanganan dan KeyRing-nya. Atribut ini adalah principal_keyring, principal_key, blockchain, schema, secondary_key, amount_token_scaled, token_symbol, contract_address, chain_id, max_fee_atomic, payload, dan time_stamp. Untuk mengetahui tabel lengkap dan perilaku setiap blockchain, lihat Menulis aturan kebijakan transaksi.
• Kolom metadata transaksi, yang ditetapkan oleh inisiator di CreateTransaction.

Tabel berikut menjelaskan atribut metadata:

Kolom Transaction.metadata	Atribut Cedar	Jenis cedar	Nilai
fiatAmount	context.fiat_amount	Long	Nilai transaksi dalam dolar AS (google.type.Money). currencyCode harus berupa USD, units harus berupa nol atau lebih, dan nanos harus berupa 0.
validity	context.validity	Long	Durasi masa berlaku transaksi (google.protobuf.Duration), dalam detik bulat. Harus lebih dari 0 detik, tanpa pecahan detik.
principalValue1	context.principal_value1	String	Nilai apa pun yang Anda tentukan, hingga 256 karakter, misalnya trading desk atau pusat biaya.
principalValue2	context.principal_value2	String	Nilai apa pun yang Anda tentukan, hingga 256 karakter, misalnya tiket internal atau ID pihak lawan.

Aturan berikut berlaku untuk metadata:

• Kolom yang tidak ditetapkan tidak ada dalam konteks. Jika transaksi tidak memiliki fiatAmount, context.fiat_amount tidak ada, dan kebijakan yang membacanya akan gagal dievaluasi. Periksa atribut dengan has terlebih dahulu, seperti dalam context has fiat_amount && context.fiat_amount <= 10000.
• Metadata yang tidak valid akan menggagalkan permintaan. Jika kolom melanggar aturan dalam tabel sebelumnya, misalnya fiatAmount di EUR atau dengan nanos bukan nol, validity 0 detik, atau principalValue1 lebih dari 256 karakter, CreateTransaction akan gagal dengan INVALID_ARGUMENT dan tidak ada kebijakan yang dievaluasi.
• Instance tidak memeriksa metadata terhadap transaksi. fiatAmount adalah nilai transaksi yang dinyatakan oleh inisiator. Penanda tangan lain melihat metadata di Transaction.metadata dan policyEvaluationRecord.evaluationContext sebelum mereka mengizinkannya. Untuk membatasi jumlah on-chain secara independen dari metadata, periksa context.amount_token_scaled dan context.contract_address.
• Metadata tidak dapat diubah setelah transaksi dibuat.

KeyRing

KeyRing mengelompokkan kunci. Setiap konteks transaksi memiliki principal_keyring dan principal_key, sehingga aturan dapat berlaku untuk setiap kunci dalam KeyRing, termasuk kunci yang dibuat nanti, dan KeyRing dapat menjadi entri dalam KeyList. Untuk mengetahui informasi selengkapnya dan contoh aturan, lihat KeyRings.

KeyLists

KeyList adalah daftar alamat blockchain bernama yang dapat dirujuk oleh kebijakan, misalnya sebagai daftar tujuan yang diizinkan. Setiap entri adalah salah satu dari hal berikut:

• Entri manual (manualEntry): alamat yang tidak dikelola oleh instance, dengan kolom source dan reason opsional.
• Kunci dalam instance (key): cocok dengan alamat kunci.
• KeyRing dalam instance (keyRing): cocok dengan alamat setiap kunci aktif di KeyRing, termasuk kunci yang dibuat setelah entri ditambahkan.

KeyList dapat berubah setelah kebijakan disetujui. Saat Anda menambahkan atau menghapus entri dengan AddKeyListEntries atau RemoveKeyListEntries, setiap kebijakan yang merujuk ke KeyList akan menggunakan entri baru dari evaluasi berikutnya, tanpa persetujuan Penulis Kebijakan baru. KeyList tidak dapat dihapus dengan DeleteKeyList saat kebijakan PENDING_ACTIVE, ACTIVE, atau PENDING_DISABLED merujuk ke KeyList tersebut.

KeyList dalam konteks Cedar

Pada waktu evaluasi, instance akan memperluas setiap KeyList menjadi Set datar dari String alamat blockchain: entri manual, ditambah alamat yang berasal dari setiap entri kunci dan KeyRing. Setiap set diteruskan ke Cedar sebagai context.key_lists["<var>KEY_LIST_ID</var>"], dengan KEY_LIST_ID adalah ID {keyList} dalam nama resource KeyList, misalnya trusted-destinations untuk projects/my-project/locations/us-central1/instances/my-instance/keyLists/trusted-destinations.

Aturan menguji keanggotaan dengan operator contains Cedar terhadap alamat tujuan yang didekode, context.secondary_key. Misalnya, untuk mengizinkan transfer hanya ke alamat di KeyList trusted-destinations:

// Assuming you created a KeyList with ID "trusted-destinations":
permit (principal, action, resource)
when { context.key_lists["trusted-destinations"].contains(context.secondary_key) };

Untuk menolak transfer ke alamat mana pun di KeyList blocked-addresses:

// Assuming you created a KeyList with ID "blocked-addresses":
forbid (principal, action, resource)
when { context.key_lists["blocked-addresses"].contains(context.secondary_key) };

Ingat hal berikut:

• Gunakan sintaksis tanda kurung, bukan sintaksis titik, untuk ID KeyList. Sintaksis titik Cedar (context.key_lists.trusted-destinations) gagal diurai jika ID berisi tanda hubung, yang dibaca Cedar sebagai pengurangan, atau dimulai dengan angka, seperti yang dapat dilakukan UUID yang dihasilkan server. Sintaksis tanda kurung, context.key_lists["<var>KEY_LIST_ID</var>"], berfungsi untuk setiap ID.
• key_lists selalu ada, dan aturan dapat membaca KeyList di dalamnya secara langsung. CreateTransactionPolicy memverifikasi bahwa setiap KeyList yang dirujuk oleh aturan ada, dan DeleteKeyList menolak untuk menghapus KeyList saat kebijakan merujuknya. Gunakan context.key_lists has "<var>KEY_LIST_ID</var>" hanya jika aturan merujuk ke KeyList yang mungkin belum ada.
• Alamat dibandingkan sebagai string. secondary_key menggunakan format yang dijelaskan dalam Aturan kebijakan transaksi tulis untuk setiap blockchain, misalnya format checksum EIP-55 huruf besar/kecil untuk Ethereum. Tambahkan entri manual dalam format yang sama.
• secondary_key transfer token Solana adalah akun token tujuan, bukan dompet pemilik. Untuk mengizinkan dompet, tambahkan akun tokennya untuk setiap mint yang Anda izinkan.

Setiap evaluasi menyelesaikan keanggotaan KeyList pada createTime transaksi, pada waktu yang sama dengan kebijakan, dan mencatat hasilnya di policyEvaluationRecord.keyListMemberships: KeyList, alamat yang diuji, apakah alamat tersebut merupakan anggota, dan entri yang cocok.

Karena KeyList mengubah hal yang diizinkan oleh kebijakan, batasi siapa yang dapat mengubahnya. Metode KeyList memerlukan roles/mpc.admin. Untuk mengetahui informasi selengkapnya, lihat Izin IAM.

Alasan penolakan

Jika policyEvaluationRecord.decision adalah DENY, policyEvaluationRecord.denyReason akan menjelaskan alasannya. Tabel berikut menjelaskan setiap alasan penolakan:

Alasan penolakan	Kapan	Menentukan kebijakan
FORBID_RULE_MATCHED	Setidaknya satu kebijakan forbid yang diterapkan cocok.	Kebijakan forbid yang cocok.
NO_PERMIT_RULE_MATCHED	Payload didekode, tidak ada kebijakan forbid yang cocok, tidak ada kebijakan yang gagal dievaluasi, dan tidak ada kebijakan permit yang cocok.	Tidak ada
EVALUATION_ERROR	Tidak ada kebijakan permit atau forbid yang cocok, dan setidaknya satu kebijakan gagal dievaluasi, misalnya karena membaca atribut opsional yang tidak ada dalam konteks.	Tidak ada. evaluationErrors mencantumkan error.
UNRECOGNIZED_PAYLOAD	Instance tidak dapat mendekode Transaction.payload atau memproyeksikannya ke dalam konteks, misalnya karena byte yang salah format, petunjuk atau operasi kontrak yang tidak didukung, atau transaksi Bitcoin dengan beberapa penerima. Tidak ada kebijakan yang dievaluasi.	Tidak ada. evaluationErrors mencantumkan error parser.

Alasan ditentukan dalam urutan berikut:

1. Jika payload tidak dapat didekode atau diproyeksikan ke dalam konteks, keputusannya adalah DENY dengan UNRECOGNIZED_PAYLOAD.
2. Jika tidak, setiap kebijakan yang diterapkan akan dievaluasi. Jika ada kebijakan forbid yang cocok, keputusannya adalah DENY dengan FORBID_RULE_MATCHED, meskipun kebijakan permit juga cocok atau kebijakan lain gagal dievaluasi.
3. Jika tidak, jika setidaknya satu kebijakan permit cocok, keputusannya adalah PERMIT. Error dari kebijakan lain masih dicatat di evaluationErrors.
4. Jika tidak, keputusannya adalah DENY dengan EVALUATION_ERROR jika ada kebijakan yang gagal dievaluasi, atau NO_PERMIT_RULE_MATCHED jika setiap kebijakan dievaluasi tanpa kecocokan.

Error dicatat bahkan saat keputusannya adalah PERMIT, jadi periksa catatan evaluasi untuk kebijakan yang tidak pernah cocok karena selalu gagal.

Skenario

Dalam Skenario 1 hingga 9, Alice (User::"[e-mail]") membuat transfer Ethereum yang valid dengan action ditetapkan ke Action::"internal_transfer_transaction" dan metadata ini, kecuali jika skenario menyatakan sebaliknya:

"metadata": {
  "fiatAmount": {"currencyCode": "USD", "units": "5000"},
  "principalValue1": "treasury-desk"
}

Transaksi tidak memiliki validity dan principalValue2.

Tabel berikut merangkum setiap skenario:

Skenario	Kebijakan atau payload yang diterapkan	Keputusan	Alasan penolakan
1	Tidak ada	DENY	NO_PERMIT_RULE_MATCHED
2	Satu permit yang cocok	PERMIT
3	Satu permit yang tidak cocok	DENY	NO_PERMIT_RULE_MATCHED
4	Dua permit, satu cocok	PERMIT
5	permit dan forbid yang cocok	DENY	FORBID_RULE_MATCHED
6	permit yang membaca atribut yang tidak ada	DENY	EVALUATION_ERROR
7	permit yang sama, dengan has	DENY	NO_PERMIT_RULE_MATCHED
8	forbid yang membaca atribut yang tidak ada, dan permit yang cocok	PERMIT
9	forbid yang memerlukan atribut	DENY	FORBID_RULE_MATCHED
10	Payload yang tidak dapat didekode	DENY	UNRECOGNIZED_PAYLOAD

Skenario 1: Tidak ada kebijakan yang diterapkan

Instance tidak memiliki kebijakan ACTIVE atau PENDING_DISABLED.

Keputusan: DENY, NO_PERMIT_RULE_MATCHED. Tanpa kebijakan permit yang cocok, setiap transaksi akan ditolak. Dalam instance baru, tidak ada transaksi yang ditandatangani secara otomatis hingga Penulis Kebijakan mengaktifkan kebijakan permit; penanda tangan harus mengizinkan setiap transaksi.

Skenario 2: Satu izin yang cocok

permit (principal, action, resource)
when { context has fiat_amount && context.fiat_amount <= 10000 };

Keputusan: PERMIT. Jumlahnya, 5.000, maksimal 10.000. determiningPolicyIds mencantumkan kebijakan ini.

Skenario 3: Satu izin yang tidak cocok

permit (principal, action, resource)
when { context has fiat_amount && context.fiat_amount <= 1000 };

Keputusan: DENY, NO_PERMIT_RULE_MATCHED. Jumlahnya, 5.000, lebih dari 1.000, dan tidak ada kebijakan lain yang mengizinkan transaksi tersebut.

Skenario 4: Dua izin, satu cocok

Kebijakan A:

permit (principal, action, resource)
when { context has fiat_amount && context.fiat_amount <= 1000 };

Kebijakan B:

permit (
  principal == User::"[e-mail]",
  action == Action::"internal_transfer_transaction",
  resource == Resource::"transaction_management"
)
when {
  context has fiat_amount && context.fiat_amount <= 25000 &&
  context has principal_value1 && context.principal_value1 == "treasury-desk"
};

Keputusan: PERMIT. Kebijakan A tidak cocok, tetapi Kebijakan B cocok. Satu kebijakan permit yang cocok sudah cukup. determiningPolicyIds hanya mencantumkan Kebijakan B.

Skenario 5: Larangan menggantikan izin

Kebijakan A:

permit (principal, action, resource)
when { context has fiat_amount && context.fiat_amount <= 10000 };

Kebijakan B:

forbid (principal, action, resource)
when { context has principal_value1 && context.principal_value1 == "treasury-desk" };

Keputusan: DENY, FORBID_RULE_MATCHED. Kedua kebijakan cocok, dan forbid menang. determiningPolicyIds hanya mencantumkan Kebijakan B.

Skenario 6: Izin membaca atribut yang tidak ada

permit (principal, action, resource)
when { context.validity <= 3600 };

Keputusan: DENY, EVALUATION_ERROR. Transaksi tidak memiliki validity, sehingga context.validity tidak ada dan kebijakan gagal dievaluasi. Tidak ada kebijakan lain yang mengizinkan transaksi. evaluationErrors mencantumkan error.

Skenario 7: Izin yang sama, dengan

permit (principal, action, resource)
when { context has validity && context.validity <= 3600 };

Keputusan: DENY, NO_PERMIT_RULE_MATCHED. context has validity adalah false, sehingga kebijakan dievaluasi ke false, bukan gagal. Transaksi masih ditolak, tetapi alasannya menunjukkan bahwa kebijakan dievaluasi dan tidak cocok.

Skenario 8: Larangan membaca atribut yang tidak ada

Kebijakan A:

permit (principal, action, resource)
when { context has fiat_amount && context.fiat_amount <= 10000 };

Kebijakan B:

forbid (principal, action, resource)
when { context.principal_value2 == "sanctioned-counterparty" };

Keputusan: PERMIT. Transaksi tidak memiliki principalValue2, sehingga Kebijakan B gagal dievaluasi dan dilewati. Kebijakan A cocok. determiningPolicyIds mencantumkan Kebijakan A, dan evaluationErrors mencantumkan error dari Kebijakan B.

Perhatian: Kebijakan forbid yang gagal dievaluasi tidak akan menolak transaksi. Inisiator dapat mengabaikan kolom metadata untuk melewati kebijakan forbid yang membacanya. Untuk menolak transaksi yang tidak memiliki atribut, gunakan has atau unless seperti yang ditunjukkan dalam Skenario 9.

Skenario 9: Larangan yang memerlukan atribut

Kebijakan A adalah kebijakan permit dari Skenario 8. Kebijakan B:

forbid (principal, action, resource)
unless { context has fiat_amount };

Keputusan: PERMIT untuk transaksi dalam skenario ini, yang memiliki fiatAmount. Jika Alice tidak menyertakan fiatAmount, keputusannya adalah DENY, FORBID_RULE_MATCHED: context has fiat_amount salah, sehingga kebijakan forbid cocok. Kebijakan ini tidak akan gagal dievaluasi karena hanya menggunakan has.

Untuk menggabungkan atribut yang diperlukan dengan pemeriksaan nilainya dalam satu kebijakan forbid, periksa atributnya terlebih dahulu:

forbid (principal, action, resource)
unless { context has fiat_amount && context.fiat_amount <= 10000 };

Skenario 10: Payload yang tidak dapat didekode

Alice membuat transaksi yang payload-nya tidak dapat didekode oleh parser untuk Transaction.schema, misalnya byte RLP yang terpotong, PSBT Bitcoin dengan beberapa penerima, atau transaksi Solana dengan petunjuk yang tidak didukung.

Keputusan: DENY, UNRECOGNIZED_PAYLOAD. Tidak ada kebijakan yang dievaluasi. evaluationErrors mencantumkan error parser, dan determiningPolicyIds kosong.

Catatan evaluasi

Setiap evaluasi menghasilkan PolicyEvaluationRecord yang tidak dapat diubah. Objek ini ditampilkan di Transaction.policyEvaluationRecord dan memiliki kolom berikut:

Kolom	Nilai
decision	PERMIT atau DENY.
denyReason	Salah satu alasan penolakan. Tidak ditetapkan saat keputusannya adalah PERMIT.
determiningPolicyIds	Pada PERMIT, ID kebijakan permit yang cocok. Pada FORBID_RULE_MATCHED, ID kebijakan forbid yang cocok. Jika tidak, kosong.
evaluationErrors	Error dari kebijakan yang gagal dievaluasi, atau error parser saat denyReason adalah UNRECOGNIZED_PAYLOAD.
evaluationContext	Konteks Cedar yang menjadi dasar evaluasi kebijakan, sebagai google.protobuf.Struct. Bilangan bulat 64-bit disimpan sebagai string desimal untuk mempertahankan presisinya.
policySetVersion	Versi set kebijakan yang digunakan evaluasi.
keyListMemberships	Keanggotaan KeyList yang diselesaikan selama evaluasi.
intentDigest	Ringkasan payload transaksi berenkode hex huruf kecil yang dievaluasi. Hash bergantung pada skema payload: Keccak-256 transaksi untuk ETHEREUM_TX_V2, sighash input pertama untuk BITCOIN_TX_V2, SHA-256 pesan yang tidak ditandatangani untuk SOLANA_TX_V1, dan ringkasan penandatanganan EIP-712, keccak256(0x1901 ++ domainSeparator ++ hashStruct(message)), untuk EIP712_TYPED_DATA_V1.
evaluationTime	Waktu saat evaluasi dijalankan.