كنت أقرأ وثائق SXT وعلقت عند مسألة أقل بهرجة من براهين ZK: من المسموح له فعليًا بالكتابة في جدول.
عندما ينشئ مطوّر جدولًا باستخدام عبارة CREATE TABLE موقّعة، يمكنه اختيار واحد من ثلاثة نماذج للكتابة: الكتابة العامة، حيث يمكن لأي شخص إرسال صفوف؛ والكتابة المقيّدة بصلاحيات المالك، حيث لا يستطيع ذلك سوى المالك أو قائمة سماح؛ والكتابة المتحقَّق منها من المستخدم، حيث يتطلب كل صف توقيع المستخدم باستخدام ECDSA/ED25519، مع إمكانية التحقق اختياريًا عبر zkTLS أو المفهرِس.
يعجبني أن هذه الصلاحيات لا تُعامل كأنها تناسب الجميع على حد سواء. فخلاصة الأنشطة العامة، ومجموعة البيانات التي يملكها بروتوكول، والسجلات التي يرسلها المستخدمون، لكل منها افتراضات مختلفة بشأن الثقة. ويمكن أيضًا تفويض الملكية عبر رموز تفويض Biscuit، لذا ليس من الضروري أن تظل السيطرة بيد المحفظة التي أنشأت الجدول.
لا أعتقد أن هذه المرونة عيب بحد ذاتها. لكنها تضع قرارًا حقيقيًا بين يدي المطوّر: يمكن لطبقة البيانات إنفاذ السياسة المحددة لها، لكنها لا تستطيع إنقاذ التطبيق من اختيار سياسة متساهلة. وفي حالة الأصول المُرمَّزة أو سجلات DeFi، قد تكون لسياسة كتابة سيئة عواقب قبل وقت طويل من طرح أي شخص سؤالًا ذكيًا بلغة SQL.
ما زلت أتساءل إن كان المطوّرون سيعتبرون صلاحيات الجداول جزءًا أساسيًا من تصميم الأمان، أم مجرد خانة إعداد أخرى ينقرون عليها ويمضون. ما الخيار الافتراضي الذي ينبغي اعتماده لمجموعات البيانات الحساسة: الكتابة التي يتحكم بها المالك أم الصفوف الموقّعة من المستخدمين؟
#SXT @SpaceandTime $SXT
#sxt $SXT @SpaceandTime #SXT
عندما ينشئ مطوّر جدولًا باستخدام عبارة CREATE TABLE موقّعة، يمكنه اختيار واحد من ثلاثة نماذج للكتابة: الكتابة العامة، حيث يمكن لأي شخص إرسال صفوف؛ والكتابة المقيّدة بصلاحيات المالك، حيث لا يستطيع ذلك سوى المالك أو قائمة سماح؛ والكتابة المتحقَّق منها من المستخدم، حيث يتطلب كل صف توقيع المستخدم باستخدام ECDSA/ED25519، مع إمكانية التحقق اختياريًا عبر zkTLS أو المفهرِس.
يعجبني أن هذه الصلاحيات لا تُعامل كأنها تناسب الجميع على حد سواء. فخلاصة الأنشطة العامة، ومجموعة البيانات التي يملكها بروتوكول، والسجلات التي يرسلها المستخدمون، لكل منها افتراضات مختلفة بشأن الثقة. ويمكن أيضًا تفويض الملكية عبر رموز تفويض Biscuit، لذا ليس من الضروري أن تظل السيطرة بيد المحفظة التي أنشأت الجدول.
لا أعتقد أن هذه المرونة عيب بحد ذاتها. لكنها تضع قرارًا حقيقيًا بين يدي المطوّر: يمكن لطبقة البيانات إنفاذ السياسة المحددة لها، لكنها لا تستطيع إنقاذ التطبيق من اختيار سياسة متساهلة. وفي حالة الأصول المُرمَّزة أو سجلات DeFi، قد تكون لسياسة كتابة سيئة عواقب قبل وقت طويل من طرح أي شخص سؤالًا ذكيًا بلغة SQL.
ما زلت أتساءل إن كان المطوّرون سيعتبرون صلاحيات الجداول جزءًا أساسيًا من تصميم الأمان، أم مجرد خانة إعداد أخرى ينقرون عليها ويمضون. ما الخيار الافتراضي الذي ينبغي اعتماده لمجموعات البيانات الحساسة: الكتابة التي يتحكم بها المالك أم الصفوف الموقّعة من المستخدمين؟
#SXT @SpaceandTime $SXT
#sxt $SXT @SpaceandTime #SXT