كنت أحدّق في Zedger لمدة ثلاثة أيام، وفجأة فهمت ما نوع الشطرنج الذي يلعبه Dusk
بصراحة، عندما بدأت دراسة @Dusk كنت أتجه إلى Phoenix. إثباتات معرفة-صفرية، معاملات خصوصية… المشاريع التي تتحدث عن هذه الحزمة في السوق كثيرة، واحدة تلو الأخرى.
لكن الذي جعلني أتوقف وأعيد قراءة الورقة البيضاء هو ذلك الهيكل داخل Zedger المسمّى Sparse Merkle-Segment Trie؛ فهناك من يذكره قليل جدًا.
في نموذج الحسابات العادي، إذا أردت معرفة الرصيد، تقرأ رقمًا فقط—ولكن الثمن هو أن الشبكة بأكملها ترى تغيّر هذا الرقم. أمّا نموذج UTXO فيغيّر الفكرة: تقسيم المال إلى قطع صغيرة مبعثرة، بحيث لا يستطيع أحد رؤية الصورة كاملة. ومع ذلك، عندما تضع هذه الأشياء في التسوية المالية، تصبح الأمور غير مريحة؛ فالمؤسسات تحتاج إلى دفتر حسابات يمكن تدقيقه ومطابقته، ويمكنه توزيع الأرباح بحسب الحصص، لا مجرد قطع لا يمكن تتبّعها.
ما تفعله Zedger هو تمكين مالك الحساب من صيانة دفتر مجزّأ بنفسه: كل مرة تحدث فيها تغييرات، يتم تحديث جذر محلي فقط في شجرة Merkle واحدة. لا يستطيع الآخرون رؤية التفاصيل، لكن يمكن لجهة الرقابة أو التدقيق—بمجرد حصولها على مفاتيح مناسبة—التحقق من مدى توافق جزء معيّن. هذا ليس طريقًا من نوع: "إما عُري كامل أو ظلام كامل" كما نفهم عادة. بل إنه يقدّم حالة وسط يمكن كشفها عند الحاجة. أمور مثل توزيع الأرباح، وحقوق التصويت، وحدود الحصص—وهي تعقيدات موجودة في الأوراق المالية—مدعومة أصلاً بهذا الهيكل، دون الحاجة إلى ترقيع إضافي.
بعد سنوات من عملي في هذا المجال، رأيت الكثير من المشاريع تتحدث عن الامتثال على لسانها، لكن التنفيذ كان كله مجرد هواء. حزمة Zedger هذه مكتوبة فعليًا في منطق الكود. إن لم تكن مقتنعًا، يمكنك الرجوع إلى مستودعها المفتوح. ومع ذلك، فهي ليست علاجًا سحريًا؛ فالبنية المعقدة تعني تكلفة أعلى في التنفيذ والتدقيق. في النهاية، هل يمكن تسوية الحساب بشكل مثالي أم لا، يعتمد على أمثلة الإنزال الواقعية للمؤسسات—وما زال من المبكر جدًا إصدار حكم نهائي.
في النهاية، المسألة في التمويل هي البحث المستمر عن نقطة توازن بين الخصوصية والثقة. لا أحد يفترض به أن يُكشف بالكامل، ولا أحد يمكنه ألا يُسأل إلى الأبد. التصميم تحت رقم $DUSK ، إلى حد ما، يجيب عن سؤال أقدم: كم ينبغي للمرء أن يعرّض نفسه للعالم كي يكون آمنًا؟ #dusk
بصراحة، عندما بدأت دراسة @Dusk كنت أتجه إلى Phoenix. إثباتات معرفة-صفرية، معاملات خصوصية… المشاريع التي تتحدث عن هذه الحزمة في السوق كثيرة، واحدة تلو الأخرى.
لكن الذي جعلني أتوقف وأعيد قراءة الورقة البيضاء هو ذلك الهيكل داخل Zedger المسمّى Sparse Merkle-Segment Trie؛ فهناك من يذكره قليل جدًا.
في نموذج الحسابات العادي، إذا أردت معرفة الرصيد، تقرأ رقمًا فقط—ولكن الثمن هو أن الشبكة بأكملها ترى تغيّر هذا الرقم. أمّا نموذج UTXO فيغيّر الفكرة: تقسيم المال إلى قطع صغيرة مبعثرة، بحيث لا يستطيع أحد رؤية الصورة كاملة. ومع ذلك، عندما تضع هذه الأشياء في التسوية المالية، تصبح الأمور غير مريحة؛ فالمؤسسات تحتاج إلى دفتر حسابات يمكن تدقيقه ومطابقته، ويمكنه توزيع الأرباح بحسب الحصص، لا مجرد قطع لا يمكن تتبّعها.
ما تفعله Zedger هو تمكين مالك الحساب من صيانة دفتر مجزّأ بنفسه: كل مرة تحدث فيها تغييرات، يتم تحديث جذر محلي فقط في شجرة Merkle واحدة. لا يستطيع الآخرون رؤية التفاصيل، لكن يمكن لجهة الرقابة أو التدقيق—بمجرد حصولها على مفاتيح مناسبة—التحقق من مدى توافق جزء معيّن. هذا ليس طريقًا من نوع: "إما عُري كامل أو ظلام كامل" كما نفهم عادة. بل إنه يقدّم حالة وسط يمكن كشفها عند الحاجة. أمور مثل توزيع الأرباح، وحقوق التصويت، وحدود الحصص—وهي تعقيدات موجودة في الأوراق المالية—مدعومة أصلاً بهذا الهيكل، دون الحاجة إلى ترقيع إضافي.
بعد سنوات من عملي في هذا المجال، رأيت الكثير من المشاريع تتحدث عن الامتثال على لسانها، لكن التنفيذ كان كله مجرد هواء. حزمة Zedger هذه مكتوبة فعليًا في منطق الكود. إن لم تكن مقتنعًا، يمكنك الرجوع إلى مستودعها المفتوح. ومع ذلك، فهي ليست علاجًا سحريًا؛ فالبنية المعقدة تعني تكلفة أعلى في التنفيذ والتدقيق. في النهاية، هل يمكن تسوية الحساب بشكل مثالي أم لا، يعتمد على أمثلة الإنزال الواقعية للمؤسسات—وما زال من المبكر جدًا إصدار حكم نهائي.
في النهاية، المسألة في التمويل هي البحث المستمر عن نقطة توازن بين الخصوصية والثقة. لا أحد يفترض به أن يُكشف بالكامل، ولا أحد يمكنه ألا يُسأل إلى الأبد. التصميم تحت رقم $DUSK ، إلى حد ما، يجيب عن سؤال أقدم: كم ينبغي للمرء أن يعرّض نفسه للعالم كي يكون آمنًا؟ #dusk