اعتقدت أن الجزء المثير للاهتمام هو بنية التحصين (staking) في بابل. لكن اتضح أنها كانت فقرة واحدة فقط في المستندات القانونية التي ظلت تدفعني للعودة إليها.
جاء في البند الذي ينص على أنه لن تكون هناك مسؤولية على أي من أطراف بابل (Babylon Parties)، بما في ذلك الأعضاء أو الممثلين أو الوكلاء، وأنه سيقع خارج نطاق المسؤولية، فبدت في البداية كحماية قانونية عادية. وبعد قراءتها إلى جانب تصميم البروتوكول ومسؤوليات المدققين (validators)، بدأت تبدو أكثر ارتباطًا بالبنية مما توقعت.
يواصل البروتوكول دفع القرارات المهمة نحو قواعد تشفيرية وسلوك المدققين والظروف المحددة مسبقًا بدلًا من الاعتماد على مشغّل مركزي لحل المشكلات لاحقًا. تعكس اللغة القانونية الاتجاه نفسه. إذا لم يكن بالإمكان حصر المسؤولية في مؤسسة واحدة، فلا بد أن تأتي الموثوقية من التنسيق عبر مشاركين مستقلين كثيرين.
وهذا يغيّر طريقة تفكيري في المخاطر التشغيلية. لم يعد الأمر متعلقًا فقط بما إذا كان البرنامج يعمل أم لا. بل يتعلق بما إذا كانت الحوافز تظل متوافقة عندما لا يُتوقع من أحد أن يتدخل لإصلاح الأخطاء بعد حدوثها. يؤمّن المدققون الشبكة، وتقوم الحوكمة بتعديل المعلمات بمرور الوقت، ويقدّم بيتكوين أساس التسوية، لكن لا تَعِد أي طبقة من هذه الطبقات بمساءلة فردية إذا حدث خطأ ما.
كما لاحظت أن هذا يخلق عبئًا مختلفًا على المطورين والمُدمجين (integrators). لا يمكنهم التعامل مع البروتوكول باعتباره خدمة تقليدية مع وجود مؤسسة تقف خلف كل نتيجة. عليهم أن يفهموا افتراضات الثقة قبل أن يضخوا رأس المال أو يبنوا تطبيقات.
كلما قارنت الصياغة القانونية بالهندسة التقنية، بدا لي أنها وثيقتان مختلفتان تصفان النظام نفسه من زاويتين مختلفتين.
@BabylonLabs_io
#baby $BABY
جاء في البند الذي ينص على أنه لن تكون هناك مسؤولية على أي من أطراف بابل (Babylon Parties)، بما في ذلك الأعضاء أو الممثلين أو الوكلاء، وأنه سيقع خارج نطاق المسؤولية، فبدت في البداية كحماية قانونية عادية. وبعد قراءتها إلى جانب تصميم البروتوكول ومسؤوليات المدققين (validators)، بدأت تبدو أكثر ارتباطًا بالبنية مما توقعت.
يواصل البروتوكول دفع القرارات المهمة نحو قواعد تشفيرية وسلوك المدققين والظروف المحددة مسبقًا بدلًا من الاعتماد على مشغّل مركزي لحل المشكلات لاحقًا. تعكس اللغة القانونية الاتجاه نفسه. إذا لم يكن بالإمكان حصر المسؤولية في مؤسسة واحدة، فلا بد أن تأتي الموثوقية من التنسيق عبر مشاركين مستقلين كثيرين.
وهذا يغيّر طريقة تفكيري في المخاطر التشغيلية. لم يعد الأمر متعلقًا فقط بما إذا كان البرنامج يعمل أم لا. بل يتعلق بما إذا كانت الحوافز تظل متوافقة عندما لا يُتوقع من أحد أن يتدخل لإصلاح الأخطاء بعد حدوثها. يؤمّن المدققون الشبكة، وتقوم الحوكمة بتعديل المعلمات بمرور الوقت، ويقدّم بيتكوين أساس التسوية، لكن لا تَعِد أي طبقة من هذه الطبقات بمساءلة فردية إذا حدث خطأ ما.
كما لاحظت أن هذا يخلق عبئًا مختلفًا على المطورين والمُدمجين (integrators). لا يمكنهم التعامل مع البروتوكول باعتباره خدمة تقليدية مع وجود مؤسسة تقف خلف كل نتيجة. عليهم أن يفهموا افتراضات الثقة قبل أن يضخوا رأس المال أو يبنوا تطبيقات.
كلما قارنت الصياغة القانونية بالهندسة التقنية، بدا لي أنها وثيقتان مختلفتان تصفان النظام نفسه من زاويتين مختلفتين.
@BabylonLabs_io
#baby $BABY
