pa
كنت أفكر في سبب استمرار الصعوبة التي تواجهها العقود الذكية في اتخاذ القرارات بالاعتماد على النشاط التاريخي لسلسلة الكتل.
لنفترض بروتوكول إقراض. قد يكون لمحفظتين الرصيد الحالي نفسه تمامًا، لكن سجليهما قد يختلفان كليًا. فقد تكون إحداهما قد أمضت سنوات في الاقتراض والسداد بمسؤولية، بينما أُنشئت الأخرى بالأمس.
يمكن للعقد الاطلاع على حالتهما الراهنة. لكن كيف يقيّم كل ما حدث من قبل؟
عندها بدأت أتعمق أكثر في @SpaceandTime
لم يكن ما لفت انتباهي مجرد استخدامه Proof of SQL، بل الطريقة التي تتلقى بها العقود الذكية نتيجة فعلية دون أن تضطر إلى تنفيذ عملية قاعدة البيانات بنفسها.
هناك فرق مهم هنا.
لا يتحول العقد الذكي فجأة إلى قاعدة بيانات. بل يرسل خطة استعلام SQL مُجمّعة مسبقًا إلى QueryRouter التابع لـ Space and Time، مع دفعة وعنوان وجهة لاستدعاءٍ لاحق.
تُنفّذ عملية الاستعلام على الجداول الموجودة على SXT Chain. وينشئ النظام Proof of SQL إلى جانب النتيجة، ثم يُتحقق من الإثبات على السلسلة قبل إعادة النتيجة إلى العقد الذي طلبها.
لكن الاستدعاء اللاحق جانب آخر مثير للاهتمام.
يحتاج العقد المستقبِل إلى التحقق من أن الرد صادر عن منفّذ الموجّه المُصرّح له، ثم فك ترميز البيانات المُعادة قبل استخدامها.
بعبارة أخرى، استلام البيانات والتصرف بناءً عليها بأمان خطوتان مختلفتان.
هذا يغيّر طريقة تفكيري في البنية. تُجرى العمليات الحسابية المكثفة خارج العقد الطالب، بينما يتيح التحقق التشفيري للعقد الاعتماد على النتيجة المُعادة من دون معالجة مجموعة البيانات بأكملها بنفسه. Space and Time +1
مهلًا، هناك طبقة أخرى لا أريد إغفالها.
فالإثبات الصحيح لا يعني تلقائيًا أن المعلومات الأصلية كانت صحيحة.
إذا دخلت معلومات غير صحيحة إلى قاعدة بيانات أثناء إدخال البيانات، فإن إثبات إجراء عملية حسابية بلغة SQL على نحو صحيح باستخدام تلك البيانات المُعتمدة لا يصحح الخطأ الأصلي بطريقة سحرية. سلامة البيانات ودقتها أمران مترابطان، لكنهما ليسا متطابقين. Proof .
@SpaceandTime #sxt $SXT
كنت أفكر في سبب استمرار الصعوبة التي تواجهها العقود الذكية في اتخاذ القرارات بالاعتماد على النشاط التاريخي لسلسلة الكتل.
لنفترض بروتوكول إقراض. قد يكون لمحفظتين الرصيد الحالي نفسه تمامًا، لكن سجليهما قد يختلفان كليًا. فقد تكون إحداهما قد أمضت سنوات في الاقتراض والسداد بمسؤولية، بينما أُنشئت الأخرى بالأمس.
يمكن للعقد الاطلاع على حالتهما الراهنة. لكن كيف يقيّم كل ما حدث من قبل؟
عندها بدأت أتعمق أكثر في @SpaceandTime
لم يكن ما لفت انتباهي مجرد استخدامه Proof of SQL، بل الطريقة التي تتلقى بها العقود الذكية نتيجة فعلية دون أن تضطر إلى تنفيذ عملية قاعدة البيانات بنفسها.
هناك فرق مهم هنا.
لا يتحول العقد الذكي فجأة إلى قاعدة بيانات. بل يرسل خطة استعلام SQL مُجمّعة مسبقًا إلى QueryRouter التابع لـ Space and Time، مع دفعة وعنوان وجهة لاستدعاءٍ لاحق.
تُنفّذ عملية الاستعلام على الجداول الموجودة على SXT Chain. وينشئ النظام Proof of SQL إلى جانب النتيجة، ثم يُتحقق من الإثبات على السلسلة قبل إعادة النتيجة إلى العقد الذي طلبها.
لكن الاستدعاء اللاحق جانب آخر مثير للاهتمام.
يحتاج العقد المستقبِل إلى التحقق من أن الرد صادر عن منفّذ الموجّه المُصرّح له، ثم فك ترميز البيانات المُعادة قبل استخدامها.
بعبارة أخرى، استلام البيانات والتصرف بناءً عليها بأمان خطوتان مختلفتان.
هذا يغيّر طريقة تفكيري في البنية. تُجرى العمليات الحسابية المكثفة خارج العقد الطالب، بينما يتيح التحقق التشفيري للعقد الاعتماد على النتيجة المُعادة من دون معالجة مجموعة البيانات بأكملها بنفسه. Space and Time +1
مهلًا، هناك طبقة أخرى لا أريد إغفالها.
فالإثبات الصحيح لا يعني تلقائيًا أن المعلومات الأصلية كانت صحيحة.
إذا دخلت معلومات غير صحيحة إلى قاعدة بيانات أثناء إدخال البيانات، فإن إثبات إجراء عملية حسابية بلغة SQL على نحو صحيح باستخدام تلك البيانات المُعتمدة لا يصحح الخطأ الأصلي بطريقة سحرية. سلامة البيانات ودقتها أمران مترابطان، لكنهما ليسا متطابقين. Proof .
@SpaceandTime #sxt $SXT
