402 / 736POON

Joseph Poon

مشارك في تأليف مقترحي Lightning وPlasma

ساعد Joseph Poon في بحث سؤال بسيط: هل يجب أن تسجل البلوكشين كلها كل دفعة صغيرة؟ اقترح مع Thaddeus Dryja شبكة Lightning Network، ثم اقترح Plasma مع Vitalik Buterin. يحاول النهجان نقل جزء من العمل خارج السلسلة الأساسية مع الاحتفاظ بإمكانية إنفاذ القواعد.

Joseph Poon مؤلف مشارك لمقترحي Lightning Network وPlasma. يربط الأول قنوات الدفع ببيتكوين، بينما يبحث الثاني في بنية هرمية من سلاسل فرعية. ولفهم عمله، يفيد تتبع حركة المال وما يستطيع المستخدم فعله عندما يتوقف الآخرون عن التعاون.

شراء القهوة لا يستدعي إخبار العالم كله. لكن في الطبقة الأساسية لبيتكوين، تتحقق شبكة حواسيب من الدفعة وتسجلها في تاريخ مشترك. بحث Joseph Poon وThaddeus Dryja في تخفيف هذا العمل باستخدام قنوات الدفع. المقترح المرتبط هنا مؤرخ في 14 يناير 2016 ويحمل علامة ⁦DRAFT 0.5.9.2⁩. كان بداية مهمة لشبكة Lightning، لكن مكوناتها الحالية نتاج عمل أشخاص آخرين أيضاً. [1]

تخيل أن آنا وبافل أودعا بيتكوين في قناة. ثم يوقعان توزيعات جديدة للمبلغ: بعد دفعة، تقل حصة آنا وتزيد حصة بافل. لا يلزم إدخال كل تغيير في السجل العام، ويمكن إنفاذ التوزيع النهائي بمعاملة Bitcoin. لكن عند النزاع تهم أيضاً الاستجابة لحالة قديمة واحترام المهل. لذلك تشمل الحماية متابعة الأحداث، لا مجرد الاحتفاظ بآخر رصيد. [1]

لا يحتاج المستلم إلى قناة مباشرة مع المرسل. يمكن أن تمر الدفعة عبر مشاركين آخرين باستخدام HTLC، وهو شرط يربط الدفع بقيمة سرية ومهلة زمنية. تسمي ⁦BOLT 2⁩ القيمة المكشوفة payment_preimage وبصمتها التشفيرية المعروفة مسبقاً payment_hash. يتحقق البرنامج من تطابقهما. العثور على مسار لا يضمن نجاح الدفع: يجب استيفاء الشروط، بينما يتطلب الخطأ أو انتهاء المهلة إجراء معالجة الفشل. [3]

تحتاج المحافظ والعقد التي يطورها أشخاص مختلفون إلى قواعد مشتركة أدق من مقترح عام. تؤدي BOLTs، أي مواصفات Lightning، هذا الدور. فهي تصف الرسائل بين المشاركين ومسارات الدفع وبنية المعاملات، وتواصل التطور. المشاركة في كتابة الورقة البيضاء لا تجعل Poon مؤلف كل تغيير لاحق. لفهم برنامج حالي، يجب قراءة وثائقه والمواصفة ذات الصلة أيضاً. [2]

كتب Poon أيضاً مع Vitalik Buterin مسودة العمل Plasma بتاريخ 11 أغسطس 2017. وهي ليست قناة دفع ببيتكوين. تقترح سلاسل فرعية تعالج المعاملات وتعتمد على سلسلة أم، مثل Ethereum، لإنفاذ القواعد. بدلاً من شبكة اتفاقات بين أزواج من المشاركين، تظهر بنية هرمية من البلوكشين. تشابه هدف نقل العمل خارج الطبقة الأساسية لا يعني تطابق الآليات أو المخاطر. [4]

تنشر Plasma عادة على السلسلة الجذرية التزامات تشفيرية صغيرة فقط، تشبه بصمات سجلات قابلة للفحص. تبقى التفاصيل في مكان آخر. تساعد البصمة على التحقق من بيانات مقدمة، لكنها لا تسمح بقراءة بيانات مفقودة. وإثبات الاحتيال يحتاج إلى السجلات المعنية. لذلك يبقى حجبها مشكلة مستقلة: نشر hash لا يضمن حصول المستخدم على كل ما يلزم للدفاع عن أمواله. [4]

في Plasma، من المهم كيف يسحب المستخدم أمواله إذا تعطلت سلسلة فرعية. يتضمن المقترح سحوبات مؤجلة وفرصة للطعن في طلب غير صحيح. ويفترض سلسلة جذرية متاحة وتعمل بصورة سليمة، بحيث يمكن تنفيذ الإجراء المطلوب عليها. هذا ليس وعداً بسحب فوري عند أي عطل. قواعد الخروج والبيانات المتاحة والمهل جزء من الأمان نفسه. [4]

يصف النص اللاحق Plasma Contracts صراحة بحثاً مجتمعياً مشتركاً. ويذكر إلى جانب Joseph Poon مساهمين مثل Dan Robinson وKelvin Fichter، من دون تأييد أي مشروع بعينه. لذلك لا يكفي اسم Plasma على موقع خدمة لإثبات توصية المؤلف بها. يظهر إسهامه في الوثائق والأسئلة التي فتحتها: ما الذي يمكن نقله خارج البلوكشين، وكيف يحتفظ المستخدم بإمكانية المطالبة بتسوية صحيحة؟ [5]

للحصول على صورة أوضح، اقرأ هذا المدخل مع Tadge Dryja, Olaoluwa Osuntokun, Lightning Network. تشير إلى هذا المدخل أيضًا Tadge Dryja, Olaoluwa Osuntokun.

DOC · 001Poon and Dryja — Lightning draft (2016)توثيق DOC · 002BOLTs — specification repositoryتوثيق DOC · 003BOLT 2 — HTLC fulfillment and expiryتوثيق DOC · 004Poon and Buterin — Plasma working draft (2017)توثيق DOC · 005Plasma Contracts — community researchتوثيق
تمت المراجعة: المصادر أولًا · ليست نصيحة استثمارية