مراجعة API3: بناء واجهات برمجة تطبيقات لامركزية للويب 3.0

تعد المنظمات المستقلة اللامركزية ، التي يطلق عليها أكثر شيوعًا DAOs ، طريقة شائعة بشكل متزايد لتوفير حوكمة عدم التدخل لمشاريع blockchain ، وأحد المشاريع التي تم تسليط الضوء عليها مؤخرًا API3.

يعد المشروع مشروعًا طموحًا يتطلع إلى معالجة “مشكلة Oracle” وإيجاد طريقة لربط واجهات برمجة التطبيقات المختلفة لموفري البيانات. إن نهج بناء شبكة API لامركزية (dAPI) هو ما لفت الانتباه كثيرًا إلى المشروع. وقد أطلق عليه أيضًا اسم “Chainlink Killer” وهذا الاسم يجلب أيضًا الكثير من الضجيج للمشروع.

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

ما هو API3?

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

تستخدم واجهات برمجة التطبيقات (API) منذ فترة طويلة بواسطة تطبيقات الويب والجوال والمبرمجون على دراية كبيرة بها. أحد الأمثلة على واجهة برمجة التطبيقات هو الطريقة التي تستخدمها العديد من بورصات العملات المشفرة لتقديم البيانات إلى المجمعين مثل Coinmarketcap.com.

شعار API3

مشروع API3 هو حل محتمل لمشكلة أوراكل. صورة عبر API3.org

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

على الرغم من أن كل هذا يبدو رائعًا لتطوير التطبيقات ، إلا أن هناك مشكلة تحدث بسبب التطور إلى dApps و Web 3.0. هذه المشكلة هي أن البنية التحتية لواجهة برمجة التطبيقات غير متوافقة مع هذه التقنيات الجديدة. ومع ذلك ، تعمل API3 على تمكين مزودي بيانات API الأقدم من توصيل مصادر بياناتهم بالعقود الذكية دون الحاجة إلى وسيط تابع لجهة خارجية. إنهم يحققون ذلك من خلال شبكة API blockchain اللامركزية لـ dAPI.

عرض قيمة dAPI

قبل حل API3 ، كان يُعتقد أن تقنية oracle يمكنها توفير بيانات للعقود الذكية كحل وسيط. واحد من أشهر هؤلاء هو Chainlink. يحتوي حل Chainlink على عقدة تقع بين موفر واجهة برمجة التطبيقات والعقد الذكي الذي يتطلب بيانات. تكمن المشكلة في أن هذا يضيف وسيطًا جديدًا للعملية ، وأحد المبادئ التوجيهية في اللامركزية هو إزالة حلول الطرف الثالث.

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

تشينلينك أوراكل

يتم توزيع الطلبات على Chainlink عبر كل من أوراكل ومصادر البيانات.

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

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

مشكلة أوراكل

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

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

مشكلة أوراكل

ما الذي يجب على blockchain فعله عندما يحتاج إلى بيانات خارج السلسلة؟ صورة عبر InfoQ.com

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

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

أدى ذلك إلى إنشاء Chainlink.

تشينلينك أونشين

سلوك Oracle على السلسلة كما هو محدد بواسطة Chainlink. صورة عبر: ورقة تشينلينك

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

لكن كل شيء ليس كاملا مع Chainlink. لديها مشاكل. المشاكل التي يمكن أن تحلها API3.

مشكلة API

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

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

نقل البيانات

Oracles هي مجرد طريقة واحدة لتمرير البيانات إلى blockchain. صورة عبر 3commas.io

لذلك ، بدلاً من التفكير في أوراكل باعتباره تجريدًا لواجهة برمجة التطبيقات ، فلماذا لا تستخدم فقط فلسفة التصميم الفعلية لواجهة برمجة التطبيقات في blockchain?

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

أخيرًا ، أليس من الرائع تجنب كل متجهات الهجوم المحتملة التي تم فتحها باستخدام أوراكل وتقديم البيانات في تكامل سلس دون أي مخاطر أمنية إضافية?

هذا هو بالضبط ما لا تستطيع Chainlink فعله ، ولكن ما تحاول API3 فعله.

حل API3

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

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

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

تشينلينك مقابل API3

حل chainlink (يسار) مقابل حل API3 (يمين). الصورة عبر الورق الأبيض API3

ضع في اعتبارك أن موفري البيانات بموجب API3 سيتمتعون الآن بسمعة طيبة لدعمهم. لم يعودوا مجهولين ، لكنهم يقدمون بياناتهم مباشرة إلى المستهلكين ، وإذا كانت هذه البيانات معيبة ، يتم التعرف عليها على الفور وهناك تداعيات.

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

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

Airnodes

تم تصميم Airnode ليتم نشره مرة واحدة بواسطة مزود واجهة برمجة التطبيقات ، ثم لا يتطلب ذلك

أي صيانة أخرى. الصورة عبر الورق الأبيض API3

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

إنه حل بسيط وأنيق.

كيف يعمل Airnode?

تم تطوير Airnode بواسطة API3 على شبكة Ethereum. إنه نظام خارج السلسلة يغذي البيانات إلى عقد مجمع باستخدام عقد إيثيريوم. عقد المجمّع هذا هو واجهة برمجة تطبيقات لامركزية يمكن استدعاؤها من العقود الأخرى. في جوهرها ، يعد Airnode عقدة أوراكل ، ولكن يتم تشغيله بواسطة موفري API بطريقة شبه خالية من الاحتكاك.

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

سحابة Airnodes

تعمل بوابة Airnodes API تمامًا مثل جزء من البنية التحتية للخدمات السحابية. صورة عبر مدونة API3.

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

إذا تم تمديد هذه المكافآت مباشرة إلى مزودي واجهة برمجة التطبيقات ، فقد يفتح ذلك سوقًا جديدًا بالكامل لمقدمي الخدمات ، ويقلل من تكاليف التطبيقات التي تستخدم بيانات dAPI.

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

حالات استخدام رمز API3

تعتزم API3 استخدام منظمة مستقلة لامركزية (DAO) لحكمها ، مما يعني أن كل مشارك في النظام البيئي سيكون له رأي في تطوير الشبكة وأمنها.

API3 النظام البيئي

النظام البيئي الكامل والتفاعلات على API3. الصورة عبر الورق الأبيض API3.

نتيجة لذلك ، سيكون لرمز API3 حالات الاستخدام التالية:

  • الرهان: يمكن لحاملي رمز API3 المشاركة في API3 لكسب المكافآت والمشاركة في الحوكمة على السلسلة.
  • الحكم: هناك حافز اقتصادي مباشر للتصويت ، حيث يحصل أصحاب المصلحة على جزء من إيرادات DAPI وتعد الرموز المميزة الخاصة بهم ضمانًا للتأمين على السلسلة.
  • جانبية: سيعمل مجمع Staking كضمان للتأمين على السلسلة.
  • المدفوعات: ستكون هناك رسوم اشتراك لـ dApps باستخدام شبكة dAPI. بالإضافة إلى ذلك ، سيتلقى موفرو البيانات الدفع في رموز API3.
  • النزاعات: في حالة فقدان الإيرادات بسبب عطل أو توقف أو بيانات غير صحيحة ، ستتمكن dApps التي تستخدم من فتح نزاعات لرفع دعوى تأمين. يخطط الفريق لاستخدام Kleros لحل مطالبات التأمين.

الضجيج الحوكمة

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

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

API3 DAO

مفهوم DAOs و DAOs الفرعية التي قدمتها API3. الصورة عبر الورق الأبيض API3

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

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

الميزة الأخرى للتخزين هي أنه يقلل من العرض المتداول ، وهو أمر جيد دائمًا للسعر.

فريق API3

تم تأسيس API3 بواسطة ثلاثة أفراد. يقود الفريق هيكي فانتينين الذي قاد فريق تطوير من حوالي 20 عضوًا. إنه مخضرم في قطاع آلة اللغة.

انضم إليه بوراك بينليجراي, باحث سابق في Google. وهو أيضًا رئيس قسم التكنولوجيا السابق في CLC Group و Honeycomb. وفقًا لسيرته الذاتية المنسقة عبر الإنترنت ، فإنه يقوم بأشياء أوراكل ورؤية. لديه شغف بالعقود الذكية واستخدام أحدث التقنيات في العالم الحقيقي. عمل سابقًا في شركات ناشئة وقدم استشارات بحثية مستقلة في رؤية الكمبيوتر والذكاء الاصطناعي.

هيكي بوراك ساسا

المؤسسون الثلاثة API3. الصورة عبر LinkedIn.com

المؤسس المشارك الثالث للمشروع هو ساشا ميليتش, التي تصف نفسها بأنها مهندسة برمجيات / عالمة بيانات / باحثة في مجال العملات المشفرة / blockchain. قبل انضمامها إلى API3 ، عملت في هندسة البرمجيات (كل من الشركات الناشئة الصغيرة وشركات التكنولوجيا الكبيرة بما في ذلك Facebook) ، وعلوم البيانات في رأس المال الاستثماري ، والبحث (اللغويات الحاسوبية ، والعلوم المعرفية) والتدريس (علوم الكمبيوتر ، وعلوم البيانات) في كل من الأوساط الأكاديمية والصناعية.

رمز API3

جمعت API3 3 ملايين دولار في نوفمبر الماضي في جولة تمويل خاص. تبع ذلك بيع عام في ديسمبر 2020. جمع هذا البيع العام 23 مليون دولار وتم بيع الرموز المميزة API3 على منحنى ربط يبدأ من 0.30 دولار لكل منها ويصل إلى 2.00 دولار. منذ ذلك الحين ، كان أداء الرمز المميز جيدًا للغاية ، حيث عاد بنسبة 1،300٪ تقريبًا على أساس الدولار الأمريكي للمستثمرين الأوائل.

بإجمالي توريد 100،000،000 من رموز API3 كان هناك ما مجموعه 30،000،000 تم بيعها في القطاع الخاص (10 مليون) والمبيعات العامة (20 مليون). من الجدير بالذكر أنه تم فتح الرموز المميزة العامة فقط. تخضع جميع الرموز الأخرى إما لجداول استحقاق مدتها سنتان أو ثلاث سنوات. الرموز مطلوبة للتثبيت والحوكمة أيضًا ، لذلك يبدو أن الاستثمار المبكر خطوة ذكية تمامًا.

تخصيص رمز API3

ستظل معظم الرموز المميزة API3 غير مستثمرة لمدة 2-3 سنوات. صورة عبر مدونة API3,

بدأت الرموز المميزة في التداول في 1 ديسمبر 2020 بسعر 1.30 دولار وبدأت على الفور في الارتفاع. في غضون أسبوع ، ارتفعوا بقوة فوق المستوى 2.00 دولار. كان هناك تراجع إلى ما دون 2.00 دولار في نهاية عام 2020. ارتفع السعر بشكل مطرد في أوائل عام 2021 ، وقفز بشكل حاد في منتصف يناير 2021 ، تضاعف بشكل أساسي إلى 4.70 دولار في 17 يناير 2021.

كانت هذه الحركة الحادة للأعلى جزءًا من حركة أوسع في جميع الأسماء المرتبطة بـ DeFi في ذلك الوقت ، لذلك من غير المؤكد ما إذا كانت المكاسب ستصمد ، أو ما إذا كان الرمز المميز سينجرف للأسفل في الأسابيع المقبلة.

خاتمة

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

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

الحل من API3 الذي يمكّن مزودي واجهة برمجة التطبيقات من تشغيل Airnode oracle من شأنه أن يمنحنا إمكانية التشغيل البيني مع خدمات الجهات الخارجية بطريقة لا مركزية. وسيضمن أيضًا تحفيز مزودي واجهة برمجة التطبيقات على توفير بيانات موثوقة وعالية الجودة.

عندما تفكر في العوائد الضخمة التي شهدها مشغلو العقدة في أنظمة oracle ، فمن المحتمل جدًا أن يسعد موفرو واجهة برمجة التطبيقات بالاستفادة من قدرتهم على توفير البيانات والخدمات بسهولة عبر تطبيق Airnodes سهل للغاية..

ما لم يأتي شيء متفوق ، يبدو أن API3 يقدم حلاً قويًا لمشكلة توصيل خدمات API التقليدية وتكنولوجيا blockchain اللامركزية.

من المؤكد أنه من السابق لأوانه تحديد ما إذا كان API3 سيكون الحل لمشكلة أوراكل ، لكن الأمور تبدو واعدة جدًا في هذه الأيام الأولى. قد ترغب في إبقاء عينيك على هذا المشروع ومعرفة كيف يتطور وينمو.

صورة مميزة عبر Shutterstock

إخلاء المسؤولية: هذه هي آراء الكاتب ولا ينبغي اعتبارها نصيحة استثمارية. يجب على القراء القيام بأبحاثهم الخاصة.

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me