توسيع نطاق العقود الذكية باستخدام SQL

شكر خاص لـ Jun Jiang من DePHY Network وRyan Soury من Usher Labs على الملاحظات والرؤى.

في عام 2008، انطلقت ناقوس الخطر في وول ستريت عندما انحدر المتداولون المتمرسون إلى حالة من الهياج البدائي. لقد تركت المؤسسات المالية المفرطة في الاستدانة، والتي انهارت تحت وطأة الأوراق المالية المدعومة بالرهن العقاري دون المستوى المطلوب، المصرفيين الجشعين مكشوفين ومتوسلين لإنقاذهم. دفعت البنوك المركزية، اليائسة للاحتفاظ بقبضتها على السلطة، ثمن خطايا المصرفيين من دفتر شيكات عامة الناس. لقد كشفت هذه الخيانة عن عيوب النظام النقدي المركزي، وكشفت عن الحاجة إلى نظام مالي أحدث وأكثر حرية وعدالة. وكما فصلت الثورة الأمريكية والدستور الذي أعقبها الكنيسة عن الدولة، ظهرت ثورة جديدة تسمى البيتكوين لفصل المال عن الدولة، مما مكن العديد من الحريات والحريات الأساسية لتقرير المصير.

إن تقنية البلوك تشين هي تقنية الحرية. فهي تمكننا من بناء أنظمة مالية وهوية ومعلوماتية وتنسيق اجتماعي لا تتطلب الثقة في وسيط مركزي. وتزدهر الحريات الفردية في عالم لا يتحكم فيه البنك المركزي في تدفق الأموال، ولا تتحكم فيه منصة واحدة في الخطاب الاجتماعي، ولا تتحكم فيه شركة واحدة في الهويات الرقمية.

إن العديد من الاختلافات بين هذا العالم الجديد والمكان الذي نحن فيه اليوم تكمن في القدرات التقنية لمنصات البلوك تشين. كان الجيل الأول من العقود الذكية بمثابة قمة جبل الجليد الذي مكّن أنظمة الحرية هذه؛ ومع ذلك، فهي محدودة بشكل أساسي في قدراتها. في هذه المقالة، أشرح بعض القيود الحرجة في العقود الذكية الحالية وكيف يوفر نظام جديد، "عقود SQL الذكية"، أساسًا أكثر كفاءة من الناحية التقنية لإطلاق العنان للحريات البشرية وتحقيق إمكانات البلوك تشين كمنصة حوسبة جديدة.

العقود الذكية: برمجة آلة الحقيقة

"المشكلة الجذرية... هي كل الثقة المطلوبة لجعل الأمر ناجحًا." - ساتوشي ناكاموتو

إن الخاصية الأساسية الأولية لسلسلة الكتل هي عدم القابلية للتغيير؛ فبمجرد أن يتفق عدد معين من أصحاب المصلحة (أو "العقد") في الشبكة على أن شيئًا ما صحيح، فإن سلسلة الكتل ستحتفظ بسجل دائم لهذه الحقيقة. تستخدم سلاسل الكتل مجموعة متنوعة من آليات "الإثبات" حيث تنفق العقد كميات كبيرة من القيمة في شكل قوة حوسبة أو حصة مالية أو سمعة لضمان عدم تمكن الجهات الخبيثة من التلاعب بالحقيقة.

إذا كانت عملة البيتكوين هي "آلة الحقيقة" للعملة الرقمية، فإن عملة الإيثريوم هي "آلة الحقيقة" للمنتجات المالية الأكثر تعقيدًا. تعمل عملة الإيثريوم على توسيع قدرات عملة البيتكوين من خلال إنشاء مساحة تصميم قابلة للبرمجة حيث يمكن للمطورين تنفيذ أي منطق ليتم نشره والتحقق منه وتنفيذه عبر سلسلة من العقد. وهذا يعني أنه يمكننا الآن إنشاء أنظمة تزيل الحاجة إلى الثقة في سلطة مركزية تتجاوز العملة فقط! يمكن لأي نظام يتطلب سلطات مركزية - مثل الإقراض، وسندات العقارات، ومعلومات الهوية، ووسائل التواصل الاجتماعي، والمقاييس الاقتصادية، وما إلى ذلك - أن يعمل الآن بدون وسطاء مركزيين. هذا عالم جديد تمامًا!

العقد الذكي هو برنامج يكتبه المطورون وينشرونه على blockchain، وهي المنصة التي يستخدمها المطورون لإنشاء تطبيقات لامركزية. لا يعني مصطلح "العقد الذكي" عقدًا قانونيًا حيث يكون طرفان ملزمين بحقوق والتزامات معينة. بدلاً من ذلك، يعني "العقد الذكي" ببساطة أن التطبيق مضمون للعمل تمامًا كما هو مكتوب في الكود إلى أجل غير مسمى. تضمن عقود الإقراض أن المقترضين والمقرضين يمكنهم دائمًا إجراء المعاملات. تضمن عقود العقارات أن الأشخاص يمكنهم دائمًا التحقق من ملكية العقار ونقلها. العقد الذكي هو تطبيق حيث يصبح الكود قانونًا.

أطلق ستيف جوبز على الكمبيوتر اسم "دراجة للعقل". وتضمن العقود الذكية عدم سقوط العجلات أبدًا.

عقود الإيثريوم الذكية: قمة جبل الجليد

"لا يتعلق التشفير بتداول الرموز فقط، بل إنه جزء من فلسفة أوسع لحماية الحرية والخصوصية والحفاظ على السلطة في أيدي الرجل الصغير." - فيتاليك بوتيرين

على الرغم من أن عقود الإيثريوم الذكية قدمت عالمًا جديدًا بالكامل من المنتجات اللامركزية، إلا أن القيود الأساسية في تصميمها وقدراتها على معالجة البيانات تمنعها من أن تكون فعالة في العديد من التطبيقات خارج نطاق العملات المشفرة.

في Solidity (لغة برمجة لـ Ethereum)، يتم تخزين بيانات العقد في أزواج مفتاح-قيمة. وعلى الرغم من أن الهياكل (مجموعات المتغيرات) والتعيينات (مجموعة أزواج المفتاح-القيمة) تقدم طرقًا مفيدة لتنظيم البيانات، إلا أنه لا يمكن استرجاع جميع البيانات إلا من خلال مفتاحها. فكر في عقد نظري لتخزين بيانات هوية المستخدم:

 contract IdentityStorage { // Struct to store KYC details struct identity { string fullName; string dateOfBirth; string residentialAddress; } // mapping a country to its citizens to their info // "Canada" => 0x123… => {Vitalik Buterin, 01/31/1994, ...} mapping(string => mapping(address => identity)) public idData; //...rest of contract }

في هذا العقد، لا يمكن استرداد سجل هوية المستخدم إلا من خلال معرفة بلد المستخدم وعنوان المحفظة. ما لم يقم مُنشئ العقد بإعادة تصميم العقد الذكي بحيث يكون به تكلفة عالية لمعالجة البيانات، فلا توجد طرق أخرى لمستخدم العقد لاسترداد سجل الهوية. في النهاية، يحد تخزين البيانات في أزواج من القيمة الرئيسية من كيفية الوصول إلى البيانات ومعالجتها.

على وجه الخصوص، فإن إدارة البيانات في عقود Ethereum الذكية تطرح مشكلتين أساسيتين: الاعتماد على الفهرس والاعتماد على مسار الوصول.

اعتماد المؤشر

تعني الاعتمادية على الفهرس أنه للوصول إلى قطعة معينة من البيانات، يجب أن تكون البيانات متاحة في فهرس. الفهرس هو بنية بيانات تبحث بكفاءة عن معرف فريد داخل مجموعة. في عقد KYC المثال أعلاه، لا يمكن الوصول إلى السجلات إلا من خلال عنوان Ethereum الدقيق المستخدم للمفتاح. يمنع هيكل الفهرسة الصارم هذا مستخدمي العقد من الاستعلام عن البيانات بناءً على معايير أخرى، مثل "أي المستخدمين لديهم هذا العنوان السكني؟" أو "ما هي النسبة المئوية للمستخدمين الذين لديهم هذا الرقم الوطني والذين ولدوا بعد 1 يناير 1970؟" بدون القدرة على إجراء مثل هذه الاستعلامات، يفتقر المطورون إلى المرونة اللازمة لتجميع وتحليل وبناء منطق التطبيق حول بيانات العقد. عندما يحتاج المطورون إلى هذه المرونة الإضافية، مثل استرداد سجل الهوية بالاسم الكامل، يجب إعادة هيكلة العقد بالكامل. في Ethereum، يمكن أن تؤدي إعادة هيكلة الفهارس أيضًا إلى زيادة تكاليف الغاز للعقد، مما يعيق قابلية استخدام العقد.

اعتماد مسار الوصول

يشير اعتماد مسار الوصول إلى إمكانية الوصول إلى البيانات وفهمها فقط من خلال مسار استرداد محدد. في العقد المثال، فإن معرفة بلد فيتاليك وعنوان المحفظة من شأنه أن يسمح للمطور باسترداد سجل هويته. ومع ذلك، فإن معرفة عنوان المحفظة فقط لن يسمح للمطور بالحصول على بلد المنشأ لفيتاليك. وعلاوة على ذلك، حتى إذا كان لدى المطور عنوان محفظة فيتاليك، فلن يتمكن من الحصول على سجل هويته ما لم يكن يعرف أيضًا بلد المنشأ (مفتاح "كندا"). تم إصلاح مسار الوصول إلى سجل هوية فيتاليك؛ إذا احتاج المطور إلى محاولة استرداد سجله فقط من خلال عنوان المحفظة، فيجب إعادة هيكلة العقد بالكامل. يعني اعتماد مسار الوصول أن البيانات يمكن الوصول إليها وذات مغزى فقط في اتجاه واحد، مما يحد من القدرة على الاستعلام عن البيانات أو تفسيرها من وجهات نظر مختلفة.

تشكل مسارات الوصول والفهرس تحديات كبيرة للتطبيقات التي تتطلب نموذج بيانات معقدًا أو متطورًا. في حين أن العملات المشفرة لديها هياكل بيانات بسيطة يمكن تنفيذها على Ethereum (رموز ERC20 هي في الأساس مجرد تعيين للعناوين للأرصدة)، فإن هذه التحديات تصبح إشكالية للتطبيقات الأكثر كثافة في البيانات. عندما يحتاج التطبيق إلى تخزين نموذج بيانات معقد والاستعلام عنه والتلاعب به، فإن تخزين القيمة الأساسية لـ Ethereum يجعل إدارة البيانات أكثر تقييدًا بشكل كبير، مما يجعل من الصعب بناء وصيانة التطبيقات التي تتطلب إدارة بيانات معقدة.

درس تاريخي مختصر: النموذج العلائقي

"التاريخ لا يكرر نفسه، لكنه يتشابه في كثير من الأحيان" - مارك توين

في عام 1970، نشر إيدجار ف. كود، وهو عالم كمبيوتر في شركة آي بي إم، ورقة بحثية بعنوان "نموذج علائقي للبيانات لبنوك البيانات المشتركة الكبيرة". في ذلك الوقت، كان النوع الأكثر شيوعًا من قواعد البيانات التطبيقية هو "قاعدة البيانات الهرمية"، والتي استخدمت بنية صلبة تشبه الشجرة حيث يتم تخزين كل قطعة من البيانات تحت دليل رئيسي، على غرار كيفية تنظيم الملفات على جهاز كمبيوتر. جادل كود ضد قاعدة البيانات الهرمية، واقترح قاعدة بيانات علائقية أحدث وأبسط وأكثر كفاءة بكثير مع بنية جدولية.

تعني البنية الشبيهة بالشجرة لقاعدة البيانات الهرمية أنه لا يمكن الوصول إلى البيانات إلا من خلال النظام الصارم لفهم العلاقة بين كل جزء من البيانات والجزء الفرعي. وعلى وجه الخصوص، حدد كود ثلاث مشاكل رئيسية في النظام الهرمي:

1. الاعتماد على الترتيب: غالبًا ما تعتمد نتيجة الاستعلام على كيفية تنظيم البيانات في التخزين. إذا تم بناء تطبيق على افتراض أن البيانات سيتم الاستعلام عنها بنفس الترتيب الذي تم تخزينها به، فلا يمكن تغيير الترتيب في المستقبل.

2. الاعتماد على الفهرس: للوصول إلى قطعة بيانات معينة، يجب أن يعرف التطبيق الأصل (أي الفهرس). وإلا، فإن استرداد البيانات المطلوبة أمر مستحيل.

3. اعتماد مسار الوصول: يتطلب الوصول إلى البيانات أو فهمها اتباع مسار استرجاع محدد. إذا تم تصميم التطبيق لاسترجاع البيانات باستخدام نمط وصول معين، فلن يتمكن من استرجاع أو تفسير نفس البيانات باستخدام مسارات بديلة.

   
   

هل يبدو هذا مألوفًا؟ على الرغم من أن عقود Ethereum الذكية لا تعتمد على الترتيب (الخرائط غير مرتبة)، فإن نفس قيود الاعتماد على الفهرس ومسار الوصول التي كانت تعيق قواعد البيانات في الستينيات والسبعينيات من القرن الماضي تعيق منصات العقود الذكية اليوم.

إن القيود على مستوى قاعدة البيانات ليست مجرد نكسة تافهة؛ فهي تقيد المطورين بشكل أساسي وتحد من أنواع التطبيقات المبنية على منصة ما. فبدلاً من التركيز على تنفيذ ميزات جديدة، يتعين على المطورين الذين يكافحون الاعتماد على الفهرس ومسار الوصول أن يبذلوا قدرًا هائلاً من الجهد للحفاظ على وظائف التطبيق الحالي. وخلال الستينيات والسبعينيات من القرن الماضي، كان استخدام قاعدة البيانات محجوزًا في المقام الأول للمهام التجارية الصارمة مثل إدارة المخزون والمحاسبة ومعالجة البيانات العامة؛ ولم يكن لدى المطورين المرونة في البيانات لإنشاء تطبيقات أكثر تعقيدًا. ومع ذلك، بعد تقديم قواعد البيانات العلائقية، ظهرت تطبيقات أكثر تعبيرًا وكثافة في البيانات، مما أدى إلى ظهور أنظمة تخطيط موارد المؤسسات، وإدارة علاقات العملاء، وأدوات الاستخبارات التجارية. وعلاوة على ذلك، مع ظهور الإنترنت، مهدت هذه التطورات الطريق لمنصات التجارة الإلكترونية وتطبيقات الوسائط الاجتماعية. يمكن للمطورين تنفيذ ميزات كانت تتطلب في السابق إعادة هيكلة قاعدة بيانات كاملة ببضعة أسطر فقط من SQL. كانت قاعدة البيانات العلائقية أكثر من مجرد تحول نموذجي؛ كانت منصة لإنشاء الفئات مكنت تطبيقات جديدة بشكل أساسي من الظهور.

اليوم، أصبحت منصات البلوك تشين مشابهة لأجهزة الكمبيوتر وقواعد البيانات في سبعينيات القرن العشرين. ويعني الافتقار إلى معالجة البيانات القادرة على مستوى البلوك تشين عدم قدرة المطورين على تنفيذ تطبيقات لامركزية أكثر تعقيدًا وكثافة في البيانات. وإذا كان الاستخدام الأساسي للبلوك تشين سيتوسع إلى ما هو أبعد من العملات المشفرة، فنحن بحاجة إلى منصات بلوك تشين ذات وظائف معالجة بيانات أكثر قدرة.

عقود SQL الذكية: نموذج أكثر مرونة

"مقياس الذكاء هو القدرة على التغيير" - ألبرت أينشتاين

وكما أدى تسويق قواعد البيانات العلائقية في ثمانينيات القرن العشرين إلى انتشار تطبيقات جديدة، فإن دمج قواعد البيانات العلائقية في منصات البلوك تشين لديه نفس الإمكانات لإعادة تشكيل أنواع التطبيقات اللامركزية التي يمكن إنشاؤها.

في Kwil، نعمل على بناء منصة blockchain ولغة عقود ذكية تسمح للمطورين ببناء تطبيقات لامركزية تستفيد من التعبير الكامل لـ SQL. مع Kwil، يمكن للمطورين الاستفادة من مرونة النموذج العلائقي لإنشاء تطبيقات لامركزية أكثر كفاءة وكثافة في البيانات.

فكر في نفس مثال تخزين الهوية من قبل. بدلاً من تخزين سجلات الهوية في خريطة حيث يمكن الوصول إلى كل سجل فقط من خلال مفتاحه، يسمح Kwil للمطورين بتخزين السجلات في جدول والاستفادة من بناء جملة SQL المرن للاستعلام عبر الجدول:

 database user_registry; table identities { address uuid primary key, name text notnull, date_of_birth int notnull, residential_address text notnull, national_id int notnull, #country_index index(national_id) } action query_by_national_id ($id) public view { SELECT * FROM identities WHERE national_id = $id; } action query_by_dob ($dob) public view { SELECT * FROM identities WHERE date_of_birth > $dob; }

في العقد الذكي الأصلي لإيثريوم، لم تكن هناك طريقة للبحث عبر الهويات وإرجاع جميع المستخدمين مع مراعاة شرط معين (مثل الهوية الوطنية) أو ربط محفظة بناءً على سمة معينة (مثل تاريخ الميلاد). يتطلب تمكين مثل هذه الوظيفة إعادة هيكلة العقد لإضافة وظائف مكلفة وتستهلك الكثير من الوقود. ومع ذلك، مع النموذج العلائقي، يمكن للمطورين تنفيذ هذه الاستعلامات دون الحاجة إلى إعادة هيكلة، وبالتالي اكتساب المزيد من مرونة معالجة البيانات دون تكبد تكاليف إضافية.

على سبيل المثال، شبكة idOS عبارة عن سلسلة كتل ذات سيادة مبنية باستخدام Kwil، مما يسمح للمستخدمين والتطبيقات اللامركزية بتخزين معلومات اعتماد المستخدم. يتيح الاستفادة من SQL عبر شبكة idOS ما يلي:

1. يمكن ربط المستخدمين واستردادهم من خلال محافظ متعددة وبيانات اعتماد وسمات.

2. بروتوكولات DeFi لإجراء تحليلات مجمعة حول المكان الذي ينتمي إليه المستخدمون.

3. بروتوكولات العملات المستقرة لتقييم المستخدمين القادمين من مناطق عالية الخطورة.

   
   

إن تمكين نموذج العلاقات وSQL على منصة blockchain اللامركزية يسمح لنا بإنشاء تطبيقات جديدة تمامًا لا يمكن أن توجد على عقود Ethereum الذكية الحالية.

خاتمة

إن النموذج العلائقي الذي أحدث ثورة في صناعة الحوسبة قبل 40 عامًا يتمتع بنفس القدرات لإحداث ثورة في صناعة blockchain اليوم. في الستينيات والسبعينيات من القرن الماضي، حد اعتماد الفهرس ومسار الوصول من فائدة قاعدة البيانات الهرمية في التطبيقات كثيفة البيانات. اليوم، يحد نفس اعتماد الفهرس ومسار الوصول من عقود Ethereum الذكية وقدرتها على تشغيل المنصات اللامركزية بنماذج بيانات معقدة. ومع ذلك، من خلال دمج النموذج العلائقي في blockchain وتزويد المطورين بنفس لهجة SQL المعبرة، يمكننا فتح أنواع جديدة من التطبيقات. تمامًا كما سرّعت قاعدة البيانات العلائقية الطلب التجاري وساعدت أجهزة الكمبيوتر على تحقيق التبني السائد، فقد تساعد منصات blockchain على القيام بنفس الشيء، وبالتالي فتح عالم رقمي أكثر حرية ولامركزية وأكثر جدارة بالثقة.