دعم عمليات النقل السري على سولانا

الخلفية

يتيح امتداد النقل السري لمنافذ إصدار Token-2022 الاحتفاظ بمبالغ التحويل وأرصدة الحسابات مشفّرةً على السلسلة. تكون الأرصدة مشفّرة، لذا يتطلّب عرضها مفاتيح فك التشفير الخاصة بالمالك، كما يستلزم الإرسال إنشاء براهين المعرفة الصفرية على جانب العميل.

هذا الدليل موجّه للفرق المُدمِجة لرموز النقل السري (المحافظ والمستكشفات والبورصات والأوصياء والفهارس) لا لجهات الإصدار التي تُهيّئ منفذ الإصدار. إذا كنت تبني التدفق الأساسي من الصفر، فابدأ بالصفحات التفصيلية المرتبطة أدناه؛ يركّز هذا الدليل على ما يحتاج منتجك إلى تنفيذه لدعم هذه الرموز بشكل جيد.

تظل عناوين الحسابات ومنفذ الإصدار ومالك كل حساب عامّةً للعموم. المبالغ والأرصدة فقط هي المشفّرة، لذا يبقى كل شيء آخر مرئيًا، بما في ذلك هوية المتعاملين مع بعضهم. هذا يمنح سرية من المراقبين العامين، لا مجهولية تامة.

الموارد

• نظرة عامة على النقل السري والأدلة التفصيلية
• كود Rust للامتداد
• @solana-program/token-2022 عميل JS (التعليمات، وتحليل حالة الحساب، واشتقاق المفاتيح، ومساعدات النقل السري عالية المستوى)
• @solana/zk-sdk حزمة WASM SDK (أوليات التشفير وتوليد بيانات البراهين)
• @solana-program/zk-elgamal-proof عميل JS (تعليمات التحقق من البراهين)
• spl-token-client حزمة Rust (مساعدات شاملة عالية المستوى بلغة Rust)

ملخّص سريع

• لكل token account سري رصيد عام بالإضافة إلى رصيد معلّق ورصيد متاح مشفّرَين. يمكن للرمز التنقل بحرية بين الحالتين العامة والسرية.
• لعرض الرصيد السري تحتاج إلى مفاتيح المالك. يُوصى باشتقاقها من محفظة المالك، وفك تشفير الرصيد المتاح باستخدام مفتاح AES (سريع)، وفك تشفير المبالغ المعلّقة بمفتاح ElGamal عند الحاجة.
• لإرسال مبالغ بشكل سري، تُنشئ براهين ZK على جانب العميل (المساواة، وصحة النص المشفّر، والنطاق)، وتُودَع عادةً في حسابات حالة سياق البرهان المؤقتة، ثم تُرسل التحويل. يوفّر كل من @solana-program/token-2022 (JS) و spl-token-client (Rust) مساعدات عالية المستوى تبني البراهين وترتّب المعاملات تلقائيًا.
• تمتد عمليات النقل السري حاليًا عبر عدة معاملات مترابطة نظرًا لأن البراهين تتجاوز حد حجم المعاملة الحالي. تعديل قادم (صيغة المعاملة v1، مع إصدار Agave v4.2) سيرفع هذا الحد ومن المتوقع أن يتيح تنفيذ النقل السري في معاملة واحدة على السلسلة.
• المحفظة التي لا تضيف أي دعم تظل تعمل: تعرض الرصيد العام وتستمر التحويلات المعيارية في العمل. تبقى الأموال السرية في متناول أي عميل يدعم السرية ويمتلك مفاتيح المالك.

المصطلحات

• زوج مفاتيح ElGamal (ElGamal keypair): keypair لكل حساب يستخدم المفتاح العام لتشفير الأرصدة وبناء براهين ZK. يتم تخزين المفتاح العام في الحساب.
• مفتاح AES: مفتاح تماثلي لكل حساب يُستخدم لتشفير "الرصيد المتاح القابل للفك" حتى يتمكن المالك من قراءة رصيده المتاح في وقت ثابت دون الحاجة إلى حل اللوغاريتم المنفصل.
• الرصيد المعلّق: رصيد مشفر للأموال المستلمة عبر الإيداعات أو التحويلات الواردة التي لم يتم تطبيقها بعد. لا يمكن إنفاقه مباشرةً.
• الرصيد المتاح: الرصيد المشفر الذي يمكن تحويله أو سحبه.
• التطبيق: الخطوة التي تنقل الرصيد المعلّق إلى الرصيد المتاح.
• حساب حالة سياق البرهان: حساب مؤقت على السلسلة يحتفظ ببرهان ZK مُتحقَّق منه مسبقاً، يُشار إليه بتعليمة سرية ثم يُغلق لاسترداد rent.
• المدقق: مفتاح ElGamal عالمي اختياري على الـ mint؛ عند تفعيله، يُشفِّر كل تحويل مبلغه إضافياً بهذا المفتاح حتى يتمكن طرف مُعيَّن من فك تشفيره.

نموذج الحساب والأرصدة

عند تهيئة حساب لعمليات النقل السرية، تخزِّن الامتداد ConfidentialTransferAccount (ضمن حقول أخرى):

• elgamal_pubkey: المفتاح العام ElGamal للحساب.
• pending_balance_lo / pending_balance_hi: نصوص مشفرة ElGamal للرصيد المعلّق، مقسَّمة إلى بتات منخفضة وعالية (فك تشفير البتات العالية أكثر تكلفةً، لذا تُحفظ بشكل منفصل).
• available_balance: نص مشفر ElGamal للرصيد القابل للإنفاق.
• decryptable_available_balance: نص مشفر AES لنفس الرصيد المتاح يمكن للمالك فك تشفيره فوراً. هذا هو الحقل المخصص للعرض.
• allow_confidential_credits / allow_non_confidential_credits: ما إذا كان الحساب يقبل حالياً الإيداعات السرية أو العامة الواردة.
• pending_balance_credit_counter و maximum_pending_balance_credit_counter: عدد الإيداعات المتراكمة في الرصيد المعلّق والحد الأقصى قبل أن يصبح التطبيق مطلوباً.

تُعاد جميع هذه الحقول في حالة الحساب المحللة عبر RPC القياسي. يمكن لأي شخص قراءة النصوص المشفرة، لكن لا يستطيع استرداد المبالغ الأساسية إلا حاملو المفاتيح.

إدارة المفاتيح

يستخدم كل حساب سري مفتاحين: keypair إلغامال للتشفير والإثباتات، ومفتاح AES لفك تشفير الرصيد بسرعة. أما كيفية إنشاء هذين المفتاحين وتخزينهما فهي خيار تكاملي. إليك بعض الخيارات الشائعة:

• الاشتقاق من توقيع المحفظة (الخيار الافتراضي الموصى به). يوقّع المالك رسالةً قانونية مفصولة حسب النطاق، وتُشتق المفاتيح من ذلك التوقيع، مما يجعلها قابلة للاستنتاج من المحفظة وحدها دون الحاجة إلى تخزينها. الـ seed محدد بشكل حتمي لكل حساب: تربطه مساعدات JS أدناه بالزوج (owner, mint)، في حين يستخدم مثال Rust عنوان token account كـ seed (وبالنسبة لـ associated token account فهما متكافئان، إذ يُشتق ذلك العنوان من المالك والمنت).
• الاشتقاق من مواد مفاتيح مستقلة. بالنسبة لمفاتيح المرور والمناطق الآمنة أو إعدادات MPC، اشتق المفاتيح من مخرج WebAuthn PRF أو مواد مفاتيح إدخال أخرى، حتى لا ترتبط المفاتيح السرية بمفتاح توقيع الحساب. يُوفّر @solana/zk-sdk كلاً من ConfidentialKeys.fromIkm و ConfidentialKeys.fromPrf لهذا الغرض.
• الإنشاء والإدارة المباشرة. قد يفضّل مزودو الحضانة وMPC إنشاء المفاتيح وإدارتها كأي مواد مفاتيح حساسة أخرى.

يتضمن عميل @solana-program/token-2022 مساعدات للمسار الموصى به:

import {
  deriveElGamalKeypairForOwnerMint,
  deriveAeKeyForOwnerMint
} from "@solana-program/token-2022";

// `owner` signs a domain-separated message; the keys are bound to (owner, mint).
const { elgamalPubkey, secretKey } = await deriveElGamalKeypairForOwnerMint({
  signer: owner,
  owner: owner.address,
  mint
});
const aesKey = await deriveAeKeyForOwnerMint({
  signer: owner,
  owner: owner.address,
  mint
});

تُعيد مساعدات الاشتقاق مادةً مفتاحية مُسلسَلة. أما مساعدات العمليات عالية المستوى (الموضحة لاحقاً) فتأخذ كائنات WASM ElGamalKeypair و AeKey، لذا أعِد bناءها من البايتات عند الحاجة إليها:

إنشاء الحسابات وتهيئتها

قبل أن يتمكن الحساب من الاحتفاظ برصيد سري، يحتاج إلى امتداد ConfidentialTransferAccount، الذي يُضيف ما يقارب 295 بايت إلى token account (أي ما يعادل تقريباً 0.0015 SOL كـ rent إضافي). تتم العملية على خطوتين: إنشاء token account، ثم تهيئة الامتداد.

تتطلب التهيئة عادةً أن يوقّع مالك الحساب ويقدّم دليلاً على امتلاكه للمفتاح العام ElGamal المُعيَّن على الحساب. يمكن لمحفظة أو بورصة إنشاء token account الأساسي وتمويله لصالح المستخدم، غير أنها لا تستطيع تهيئة امتداد السرية نيابةً عن المستخدم دون توقيعه.

لهذا السبب، تجنّب تهيئة حسابات سرية بصمت لكل مستخدم: فهي تستلزم rent إضافياً ولا تزال تحتاج إلى مشاركة المالك. قم بالتهيئة عند الاستخدام الأول، أو حين يختار المستخدم تفعيل التحويلات السرية.

يُزيل سجل ElGamal خطوة المالك لكل حساب على حدة. يُسجّل المستخدم مفتاحه العام ElGamal مرةً واحدة (بتوقيع دليل عند التسجيل)، ويكون إدخال السجل قابلاً لإعادة الاستخدام عبر كل mint. بعد ذلك، يستطيع طرف ثالث تهيئة الحسابات السرية للمستخدم باستخدام ConfigureAccountWithRegistry، دون الحاجة إلى توقيع المالك أو دليل وقت التهيئة، بل يحتاج فقط إلى دافع لـ rent. هذه هي الآلية المُوصى باستخدامها إن أردت تهيئة حسابات سرية للمستخدمين بسلاسة.

عرض الأرصدة

يُظهر التكامل المتين الرصيد العام باستخدام رصيد الرمز المميز القياسي، ويكتشف الامتداد السري، وعند إلغاء قفل المفاتيح من قِبل المستخدم، يفكّ التشفير ويعرض الرصيد المتاح.

يُقرأ الرصيد المتاح بصورة أمثل من decryptable_available_balance باستخدام مفتاح AES، وهو ثابت الزمن. ينبغي تجنّب فكّ تشفير available_balance الخاص بـ ElGamal مباشرةً لأنه يستلزم حلّ لوغاريتم تقسيمي، ولا يُوصى به للعرض الاعتيادي.

import { AeCiphertext } from "@solana/zk-sdk/bundler";
import { fetchToken } from "@solana-program/token-2022";
import { unwrapOption } from "@solana/kit";

const account = await fetchToken(rpc, tokenAccountAddress);

// `extensions` is an Option<Array<Extension>>; each extension is a tagged union.
const extensions = unwrapOption(account.data.extensions) ?? [];
const ct = extensions.find((e) => e.__kind === "ConfidentialTransferAccount");

if (ct) {
  // Fast path: decrypt the AES "decryptable available balance" for display.
  const ciphertext = AeCiphertext.fromBytes(
    new Uint8Array(ct.decryptableAvailableBalance)
  );
  // `aesKey` is the rebuilt AeKey object (see the rebuild snippet above), not raw bytes.
  const availableBalance = ciphertext?.decrypt(aesKey); // bigint | undefined
  console.log("Available (confidential):", availableBalance);
}

عندما لا يقوم المستخدم بإلغاء قفل مفاتيحه، اعرض الرصيد العام وأشر إلى وجود رصيد سري مقفل، بدلاً من عرض صفر.

استقبال التحويلات

تصل الإيداعات والتحويلات الواردة إلى رصيد معلّق وغير قابل للإنفاق حتى يتم تطبيقه. يزيد كل إيداع pending_balance_credit_counter بمقدار واحد؛ وبمجرد بلوغه maximum_pending_balance_credit_counter، لن يتمكن الحساب من استقبال مزيد من الرصيد السري المعلّق حتى يقوم المالك بتطبيق الرصيد المعلّق.

ينبغي على التكاملات التي تحتفظ بأموال نيابةً عن المستخدمين أن:

• تعرض الرصيد المعلّق والمتاح بشكل منفصل حتى يفهم المستخدمون سبب عدم إمكانية إنفاق المبلغ المُستلم للتوّ.
• تُطبّق الرصيد المعلّق نيابةً عن المستخدم في أوقات مناسبة (مثلاً قبل الإرسال) حتى لا تتعطل الأرصدة.

import { getApplyConfidentialPendingBalanceInstructionFromToken } from "@solana-program/token-2022";

// Builds a single instruction; no proofs are needed to apply.
const instruction = getApplyConfidentialPendingBalanceInstructionFromToken({
  token: tokenAccountAddress,
  tokenAccount, // decoded Token account
  authority: owner,
  elgamalSecretKey: elgamalKeypair.secret(),
  aesKey
});

راجع صفحة تطبيق الرصيد المعلّق للاطلاع على التدفق الكامل.

إرسال التحويلات

يتطلب التحويل السري ثلاثة إثباتات معرفة صفرية تُولَّد على جانب العميل:

• إثبات المساواة الذي يُثبت أن نص التشفير الجديد لرصيد المُرسل يُشفّر القيمة ذاتها الموجودة في الالتزام الجديد الذي يستطيع المُرسل فتحه.
• إثبات صحة نص التشفير الذي يُثبت أن نصوص تشفير مبلغ التحويل مُشكَّلة بصورة صحيحة وفق مفاتيح المصدر والوجهة و(عند التعيين) مفتاح المدقق.
• إثبات النطاق الذي يُثبت أن المبلغ والرصيد المتبقي للمُرسل أعداد صحيحة غير سالبة صالحة، وهو ما يمنع سكّ قيمة من لا شيء.

هذه الإثباتات أكبر مما يسمح به حد حجم المعاملات الحالي بشكل مضمّن، لذا فإن النمط المعتاد هو إنشاء حسابات حالة سياق الإثبات، والتحقق من كل إثبات فيها، والإشارة إليها من تعليمات النقل، ثم إغلاقها لاسترداد rent. يمتد ذلك عبر بضع معاملات متسلسلة. يرفع تنسيق المعاملات v1 (المُدرج مع Agave v4.2) حد الحجم، ومن المتوقع أن يتيح تشغيل نقل سري في معاملة واحدة على السلسلة، مما سيبسّط هذا التدفق.

لا يتعين عليك تجميع الإثباتات يدويًا. يوفر كلا العميلين مساعدًا رفيع المستوى يبني الإثباتات وينتج التعليمات اللازمة للإرسال:

import { getConfidentialTransferInstructionPlan } from "@solana-program/token-2022";

// Returns an instruction plan covering proof setup, the transfer, and cleanup.
const plan = await getConfidentialTransferInstructionPlan({
  rpc,
  payer, // funds rent for the temporary proof context state accounts
  sourceToken,
  mint,
  destinationToken,
  sourceTokenAccount, // decoded Token account for the source
  destinationTokenAccount, // decoded Token account for the destination,
  // or pass `destinationElgamalPubkey` directly instead
  authority: owner,
  amount,
  sourceElgamalKeypair, // ElGamal keypair for the source account
  aesKey, // AES key for the source account
  auditorElgamalPubkey // optional, read from the mint config
});

// Execute the plan with your instruction-plan executor of choice.

إذا كنت بحاجة إلى تحكم أدق، فإن عناصر البناء الأساسية متاحة أيضًا: @solana/zk-sdk يولّد بيانات كل إثبات (CiphertextCommitmentEqualityProofData، BatchedGroupedCiphertext3HandlesValidityProofData، BatchedRangeProofU128Data)، ويوفر @solana-program/zk-elgamal-proof تعليمات التحقق من الإثبات، ويوفر @solana-program/token-2022 تعليمات confidentialTransfer وحساب حالة السياق.

راجع صفحة نقل الرموز للاطلاع على تسلسل التعليمات التفصيلي.

السحب

يقوم السحب بنقل الأموال من الرصيد المتاح السري إلى الرصيد العام، وبعدها تتصرف مثل أي رصيد رمزي عادي. يتطلب السحب أيضًا إثباتات (إثبات مساواة وإثبات نطاق)، مكشوفة كـ getConfidentialWithdrawInstructionPlan في عميل JS وكـ confidential_transfer_withdraw في عميل Rust. قم بتطبيق أي رصيد معلّق أولًا لإتاحة المبلغ الكامل. راجع سحب الرموز.

الامتدادات السرية ذات الصلة

يُبنى امتدادان اختياريان على النقل السري. كلاهما يقع في المقام الأول على عاتق المُصدر، غير أن كلًا منهما يُغيّر شيئًا يجب أن يتعامل معه المُدمج:

• رسوم النقل السري. عندما يقرن سك العملة النقلَ السري بـ رسوم النقل، تستخدم عمليات الإرسال مسار النقل بالرسوم (confidential_transfer_transfer_with_fee في عميل Rust)، وتكون الرسوم المحجوزة مشفرة مثل المبلغ. إن تحصيل الرسوم المحجوزة (الحصاد والسحب) هو من مسؤولية سلطة الرسوم، لا المُدمج.
• السك والحرق السري. يُصدر السك الذي يحمل هذا الامتداد العرضَ ويحرقه بشكل سري، مما يُعطّل مسار الإيداع والسحب العام. لا يمكن نقل الرموز بين الأرصدة العامة والسرية على مثل هذا السك، لذا لا تُظهر الإيداع أو السحب له.

للاطلاع على التفاصيل على مستوى البروتوكول لكليهما، راجع توثيق الأرصدة السرية.

تحليل معاملات التحويل السري

يحتاج المستكشفون والمفهرسون إلى التعرف على نشاط التحويل السري ووسمه دون القدرة على قراءة المبالغ. يُتيح عميل @solana-program/token-2022 الدالةَ identifyToken2022Instruction لتصنيف كل تعليمة من تعليمات Token-2022، إضافةً إلى محللات خاصة بكل تعليمة (مثل parseConfidentialTransferInstruction) لفك ترميز الحسابات والحقول غير السرية. تبقى المبالغ المشفرة على هيئة نصوص مشفرة: اعرضها بوصفها سرية بدلاً من تحويل البايتات إلى أرقام.

import {
  identifyToken2022Instruction,
  Token2022Instruction,
  TOKEN_2022_PROGRAM_ADDRESS
} from "@solana-program/token-2022";

for (const ix of instructions) {
  if (ix.programAddress !== TOKEN_2022_PROGRAM_ADDRESS) continue;

  const kind = identifyToken2022Instruction(ix);
  switch (kind) {
    case Token2022Instruction.ConfidentialTransfer:
    case Token2022Instruction.ConfidentialTransferWithFee:
      console.log("Confidential transfer (amount encrypted)");
      break;
    case Token2022Instruction.ConfidentialDeposit:
      console.log("Deposit to confidential balance");
      break;
    case Token2022Instruction.ConfidentialWithdraw:
      console.log("Withdraw from confidential balance");
      break;
    case Token2022Instruction.ApplyConfidentialPendingBalance:
      console.log("Apply pending balance");
      break;
    default:
      break;
  }
}

قيود الفهرسة التي ينبغي التخطيط لها:

• لا توجد مبالغ للتحويلات السرية. تحمل ConfidentialTransfer مبالغ مشفرة، لذا لا يمكن احتساب تحليلات الحجم والتدفق وحجم التحويل منها. ضع علامة على هذه التحويلات بوصفها سرية بدلاً من تسجيل صفر أو نص مشفر خام.
• لا توجد فوارق في الرصيد. لا تُغيِّر التحويلات السرية رصيد الرمز العام، لذا فإن آلية المقارنة بين الرصيد قبل وبعد التحويل التي تعتمد عليها معظم عمليات فهرسة التحويلات لا تلتقطها. الأرصدة المعلقة والمتاحة هي نصوص مشفرة.
• الإيداعات والسحوبات واضحة. تحمل ConfidentialDeposit و ConfidentialWithdraw مبالغ نصية واضحة، لذا يمكنك فهرسة التدفق من وإلى المجموعة السرية، غير أن التحويلات داخلها تظل غير قابلة للفهرسة.
• يمتد تحويل واحد على عدة معاملات في الوقت الحالي. تُنشأ حسابات حالة سياق الإثبات وتُستخدم وتُغلق حول التحويل، لذا ربِّط المعاملات ذات الصلة بدلاً من معالجة كل منها بمعزل عن الأخرى. سيختفي هذا التعقيد عند إطلاق التحويلات السرية ذات المعاملة الواحدة (انظر أعلاه).
• يمكن فك تشفير عمليات سك المدقق. إذا كان لدى العملة مدقق عالمي وكنت تمتلك مفتاح المدقق، يمكنك فك تشفير مبالغ التحويل لتلك العملة (انظر أدناه).

المدققون والامتثال

قد تُهيِّئ أي عملة صك مدققًا عامًا باستخدام pubkey ElGamal. وعند تعيينه، يجب أن تتضمن كل عملية تحويل سري المبلغ مشفرًا بمفتاح المدقق، بحيث يتمكن حامل المفتاح السري للمدقق من فك تشفير جميع مبالغ التحويل الخاصة بذلك الصك. يشمل إثبات الصحة النص المشفر الخاص بالمدقق، لذا بوصفك مُدمِجًا لا يتعين عليك اتخاذ أي إجراء خاص في مسار الإرسال سوى تمرير مفتاح المدقق من تهيئة الصك (إذ تقرأه المساعدات عالية المستوى تلقائيًا نيابةً عنك).

إذا كان منتجك هو المدقق (كمُصدِر خاضع للتنظيم أو مزود خدمات امتثال مثلًا)، فأنت تفك تشفير مبالغ التحويل باستخدام المفتاح السري للمدقق بالطريقة ذاتها التي يفك بها المالك تشفير رصيده الخاص. ويمكن للمالكين أيضًا مشاركة مفاتيحهم الخاصة بكل حساب بشكل انتقائي مع طرف محدد دون الإفصاح عنها علنًا.

مراقبة المعاملات (KYT)

بالنسبة لمزودي خدمة اعرف معاملتك ومكافحة غسل الأموال، تُغيِّر التحويلات السرية ما يمكن رصده دون أن تُغيِّر النموذج العام:

• تحليل العناوين والرسوم البيانية لا يتأثر. يبقى المرسلون والمستقبلون وعمليات الصك وأصحاب الحسابات عامين للعيان، لذا تعمل فحوصات العناوين ومطابقة قوائم العقوبات وتحليل الرسوم البيانية للأطراف المقابلة بالطريقة ذاتها كما هو الحال مع أي رمز مميز.
• الإرشادات القائمة على المبالغ تحتاج إلى مفتاح المدقق. لا يمكن لتحليل التجزئة وإعداد تقارير العتبات وتقييم المخاطر القائم على الحجم قراءة مبالغ التحويل السرية بمفردها. تبقى مبالغ الإيداع والسحب واضحة، لذا يظل حجم التدفقات الداخلة إلى المجمع السري والخارجة منه مرئيًا.
• التغطية تأتي من نموذج المدقق. في الصكوك التي تُهيِّئ مدققًا عامًا، يمكن لمزود يعمل بمفتاح المدقق (أو يتلقى إفصاحًا انتقائيًا من المستخدم أو المُصدِر) استرداد مبالغ التحويل. ينبغي للمُصدِرين في السياقات الخاضعة للتنظيم التخطيط لتهيئة مدقق أو دعم الإفصاح الانتقائي لضمان إمكانية المراقبة.

التوافق مع الإصدارات السابقة

• يمتلك token account السري دائمًا رصيدًا عامًا. تستمر المحافظ والتطبيقات التي لا تدعم الامتداد في العمل وتعرض الرصيد العام.
• تعمل التحويلات القياسية على الرصيد العام طالما أن الوجهة تسمح بالإيداعات غير السرية.
• لا تظهر الأرصدة السرية للأدوات غير الداعمة، لكن الأموال لا تُفقد: يمكن لأي عميل يدعم السرية الوصول إليها باستخدام مفاتيح المالك.
• نظرًا لتشفير المبالغ، فإن تحليلات العرض والحجم التي تعتمد على قراءة مبالغ التحويل لن ترصد النشاط السري. خطّط لوحات المعلومات والمحاسبة مع مراعاة ذلك.

أولويات التكامل الموصى بها لكل منصة

المتطلبات العامة

المحافظ

المستكشفون والمفهرسون

البورصات والوصناء

موفرو الامتثال ومعرفة المعاملات (KYT)