إثبات نزاهتك من دون تسليم قائمة العملاء؟ لهذا حل
أكثر ما يحرج المؤسسات عند دخول هذا المجال هو أنها تريد إثبات نزاهتها، لكنها لا تريد تسليم قائمة عملائها. والنهج المتبع حاليًا ينقسم أساسًا إلى خيارين: إما تسليم العناوين وسجلات المعاملات إلى شركة لتحليل البلوك تشين وتقييمها، ما يعني كشف أوراقك كاملة لطرف ثالث؛ وإما إنشاء قائمة سماح باستخدام شجرة ميركل، وهو ما يثبت فقط أن عنوانًا معينًا موجود ضمن المجموعة، لكنه لا يثبت أن المجموعة نفسها نظيفة. جرّبت خيارًا ثالثًا عبر مسار البيانات الخاصة في SXT: وضعت القائمة الداخلية وقائمة العناوين المقيّدة المتاحة للعامة في الجدول نفسه، وجعلت الاستعلام يُرجع قيمة منطقية مع إثبات. فلا يُكشف للآخرين سوى النتيجة، من دون الإفصاح عن أي سجل. إمكانات هذا الاستخدام أوسع مما يظنه معظم الناس: يمكن تطبيقه على إثبات الاحتياطيات، وفحص العقوبات، وحتى التحقق مما إذا كانت أصول العميل تتجاوز حدًا معينًا، بحيث لا يُخرَج سوى جواب بنعم أو لا. والصعوبة التقنية الحقيقية تكمن في مواكبة التغييرات؛ فالقوائم تتغير يوميًا، ويجب إعادة إنشاء الإثباتات معها، وإلا فأنت تثبت نزاهة الوضع في الأسبوع الماضي. تعثرت في هذا الأمر مرة: استخدمت إثباتًا قديمًا للتحقق من قائمة جديدة، فأخبرني العقد بأن كل شيء على ما يرام، وشعرت حينها بقشعريرة تسري في ظهري. تعلمت لاحقًا أن أضمّن في الإثبات تجزئة إصدار البيانات، بحيث يُرفض مباشرةً إذا لم يتطابق الإصدار. لكن العقبة ليست في التشفير، بل في القائمة نفسها: من يتولى صيانتها؟ وكم مرة تُحدَّث؟ وهل يمكن تدقيق سجل تحديثاتها؟ هذه مسائل تشغيلية، وإذا كانت البيانات مليئة بالأخطاء فلن يجدي كل ذلك نفعًا. وفوق هذا، لا يزال الاعتراف القانوني بالإثباتات التشفيرية مسألة غير محسومة، ويفضّل مسؤولو الامتثال الاطلاع على تقرير مختوم. وبالمقارنة مع إثبات الاحتياطيات من Chainlink، فهذا النهج أكثر مرونة؛ إذ يتيح تنفيذ استعلامات SQL اعتباطية بدلًا من الاكتفاء بجمع الأرصدة، لكن ثمن ذلك هو تحمّل عبء هندسة الإثباتات بنفسك. أرى أن مؤسسات الأصول الواقعية (RWA) ومؤسسات الحفظ ستكون أول من يعتمد هذا النهج، لأنها بأمسّ الحاجة إلى وسيلة تثبت نزاهتها من دون كشف بياناتها. ولتنفيذه على نحو متعمق، لا بد من الجمع بين إثباتات النطاق والإثباتات التجميعية؛ كأن تثبت أن إجمالي الانكشاف أقل من الحد الأقصى، وأن أي طرف مقابل منفرد لا يتجاوز حدّه أيضًا. لا توجد حاليًا أدوات جاهزة لهذا النوع من العمل، لذا عليك تركيب الحل بنفسك. وعندما تستقر هذه الطبقة وتعمل بسلاسة، سيتغير خطاب المبيعات لدى المؤسسات من «لدينا ضوابط صارمة لإدارة المخاطر» إلى «يمكنك التحقق بنفسك».
#sxt $SXT @SpaceandTime
أكثر ما يحرج المؤسسات عند دخول هذا المجال هو أنها تريد إثبات نزاهتها، لكنها لا تريد تسليم قائمة عملائها. والنهج المتبع حاليًا ينقسم أساسًا إلى خيارين: إما تسليم العناوين وسجلات المعاملات إلى شركة لتحليل البلوك تشين وتقييمها، ما يعني كشف أوراقك كاملة لطرف ثالث؛ وإما إنشاء قائمة سماح باستخدام شجرة ميركل، وهو ما يثبت فقط أن عنوانًا معينًا موجود ضمن المجموعة، لكنه لا يثبت أن المجموعة نفسها نظيفة. جرّبت خيارًا ثالثًا عبر مسار البيانات الخاصة في SXT: وضعت القائمة الداخلية وقائمة العناوين المقيّدة المتاحة للعامة في الجدول نفسه، وجعلت الاستعلام يُرجع قيمة منطقية مع إثبات. فلا يُكشف للآخرين سوى النتيجة، من دون الإفصاح عن أي سجل. إمكانات هذا الاستخدام أوسع مما يظنه معظم الناس: يمكن تطبيقه على إثبات الاحتياطيات، وفحص العقوبات، وحتى التحقق مما إذا كانت أصول العميل تتجاوز حدًا معينًا، بحيث لا يُخرَج سوى جواب بنعم أو لا. والصعوبة التقنية الحقيقية تكمن في مواكبة التغييرات؛ فالقوائم تتغير يوميًا، ويجب إعادة إنشاء الإثباتات معها، وإلا فأنت تثبت نزاهة الوضع في الأسبوع الماضي. تعثرت في هذا الأمر مرة: استخدمت إثباتًا قديمًا للتحقق من قائمة جديدة، فأخبرني العقد بأن كل شيء على ما يرام، وشعرت حينها بقشعريرة تسري في ظهري. تعلمت لاحقًا أن أضمّن في الإثبات تجزئة إصدار البيانات، بحيث يُرفض مباشرةً إذا لم يتطابق الإصدار. لكن العقبة ليست في التشفير، بل في القائمة نفسها: من يتولى صيانتها؟ وكم مرة تُحدَّث؟ وهل يمكن تدقيق سجل تحديثاتها؟ هذه مسائل تشغيلية، وإذا كانت البيانات مليئة بالأخطاء فلن يجدي كل ذلك نفعًا. وفوق هذا، لا يزال الاعتراف القانوني بالإثباتات التشفيرية مسألة غير محسومة، ويفضّل مسؤولو الامتثال الاطلاع على تقرير مختوم. وبالمقارنة مع إثبات الاحتياطيات من Chainlink، فهذا النهج أكثر مرونة؛ إذ يتيح تنفيذ استعلامات SQL اعتباطية بدلًا من الاكتفاء بجمع الأرصدة، لكن ثمن ذلك هو تحمّل عبء هندسة الإثباتات بنفسك. أرى أن مؤسسات الأصول الواقعية (RWA) ومؤسسات الحفظ ستكون أول من يعتمد هذا النهج، لأنها بأمسّ الحاجة إلى وسيلة تثبت نزاهتها من دون كشف بياناتها. ولتنفيذه على نحو متعمق، لا بد من الجمع بين إثباتات النطاق والإثباتات التجميعية؛ كأن تثبت أن إجمالي الانكشاف أقل من الحد الأقصى، وأن أي طرف مقابل منفرد لا يتجاوز حدّه أيضًا. لا توجد حاليًا أدوات جاهزة لهذا النوع من العمل، لذا عليك تركيب الحل بنفسك. وعندما تستقر هذه الطبقة وتعمل بسلاسة، سيتغير خطاب المبيعات لدى المؤسسات من «لدينا ضوابط صارمة لإدارة المخاطر» إلى «يمكنك التحقق بنفسك».
#sxt $SXT @SpaceandTime
