هذا النص هو استمرار لسلسلة من المقالات التي أدرس فيها بنية شبكة Telegram Open Network (TON) الموزعة (المفترضة)، والتي يجري إعدادها للإصدار هذا العام. في لقد وصفت مستواها الأساسي - الطريقة التي تتفاعل بها العقد مع بعضها البعض.
فقط في حالة، اسمحوا لي أن أذكرك أنه ليس لدي أي علاقة بتطوير هذه الشبكة وأن جميع المواد تم جمعها من مصدر مفتوح (وإن لم يتم التحقق منه) - (وهناك أيضا مرافقة ، مع توضيح النقاط الرئيسية بإيجاز) والتي ظهرت في نهاية العام الماضي. إن كمية المعلومات الواردة في هذه الوثيقة، في رأيي، تشير إلى صحتها، رغم عدم وجود تأكيد رسمي لذلك.
اليوم سنلقي نظرة على المكون الرئيسي لـ TON - blockchain.
المفاهيم الأساسية
حساب (حساب). مجموعة من البيانات المحددة برقم 256 بت معرف_الحساب (غالبًا ما يكون هذا هو المفتاح العام لصاحب الحساب). في الحالة الأساسية (انظر أدناه سلسلة عمل صفر)، تشير هذه البيانات إلى رصيد المستخدم. "احتلال" محددة معرف_الحساب يمكن لأي شخص ذلك، ولكن لا يمكن تغيير قيمته إلا وفقًا لقواعد معينة.
عقد ذكي (عقد ذكي). في جوهرها، إنها حالة خاصة للحساب، مكملة بكود العقد الذكي وتخزين متغيراته. إذا كان بإمكانك في حالة "المحفظة" إيداع الأموال وسحبها منها وفقًا لقواعد بسيطة نسبيًا ومحددة مسبقًا، ففي حالة العقد الذكي تتم كتابة هذه القواعد في شكل رمز خاص بها (بصيغة تورينج كاملة معينة) لغة برمجة).
دولة البلوكشين (حالة blockchain). مجموعة حالات جميع الحسابات/العقود الذكية (بالمعنى المجرد، جدول التجزئة، حيث المفاتيح هي معرفات الحساب والقيم هي البيانات المخزنة في الحسابات).
رسالة (الرسالة). أعلاه استخدمت عبارة "أموال الائتمان والخصم" - وهذا مثال محدد للرسالة ("تحويل". ن جرام من حساب الحساب_1 لكل حساب الحساب_2"). من الواضح أن العقدة التي تمتلك المفتاح الخاص للحساب هي وحدها التي يمكنها إرسال مثل هذه الرسالة الحساب_1 - وقادر على تأكيد ذلك بالتوقيع. نتيجة تسليم مثل هذه الرسائل إلى حساب عادي هي زيادة في رصيده، ونتيجة العقد الذكي هي تنفيذ الكود الخاص به (الذي سيقوم بمعالجة استلام الرسالة). وبطبيعة الحال، هناك رسائل أخرى ممكنة أيضًا (ليس نقل المبالغ النقدية، ولكن البيانات التعسفية بين العقود الذكية).
عملية (صفقة). حقيقة تسليم الرسالة تسمى معاملة. المعاملات تغير حالة blockchain. إنها المعاملات (سجلات تسليم الرسائل) التي تشكل الكتل في blockchain. في هذا الصدد، يمكنك التفكير في حالة blockchain كقاعدة بيانات تزايدية - جميع الكتل عبارة عن "اختلافات" يجب تطبيقها بشكل تسلسلي للحصول على الحالة الحالية لقاعدة البيانات. ستتم مناقشة تفاصيل تعبئة هذه "الاختلافات" (واستعادة الحالة الكاملة منها) في المقالة التالية.
Blockchain في TON: ما هو ولماذا؟
كما ذكرنا في المقال السابق، blockchain عبارة عن بنية بيانات يتم ترتيب عناصرها (الكتل) في "سلسلة" ، وتحتوي كل كتلة لاحقة من السلسلة على تجزئة للكتلة السابقة. طرحت التعليقات السؤال التالي: لماذا نحتاج إلى بنية البيانات هذه على الإطلاق عندما يكون لدينا بالفعل DHT - جدول تجزئة موزع؟ من الواضح أنه يمكن تخزين بعض البيانات في DHT، لكن هذا مناسب فقط للمعلومات غير "الحساسة" للغاية. لا يمكن تخزين أرصدة العملات المشفرة في DHT - ويرجع ذلك أساسًا إلى عدم وجود فحوصات سلامة. في الواقع، ينمو التعقيد الكامل لبنية blockchain من أجل منع التداخل مع البيانات المخزنة فيه.
ومع ذلك، فإن blockchain في TON يبدو أكثر تعقيدًا من معظم الأنظمة الموزعة الأخرى - وذلك لسببين. الأول هو الرغبة في تقليل الحاجة إلى شوك. في العملات المشفرة التقليدية، يتم تعيين جميع المعلمات في المرحلة الأولية وأي محاولة لتغييرها تؤدي في الواقع إلى ظهور "عالم العملات المشفرة البديل". السبب الثاني هو دعم التكسير (مشاركة, مشاركة) بلوكشين. Blockchain عبارة عن هيكل لا يمكن أن يصبح أصغر بمرور الوقت؛ وعادة ما تضطر كل عقدة مسؤولة عن تشغيل الشبكة إلى تخزينها بالكامل. في الأنظمة التقليدية (المركزية)، يتم استخدام التجزئة لحل مثل هذه المشكلات: توجد بعض السجلات في قاعدة البيانات على خادم واحد، وبعضها على خادم آخر، وما إلى ذلك. في حالة العملات المشفرة، لا تزال هذه الوظيفة نادرة جدًا - على وجه الخصوص، بسبب حقيقة أنه من الصعب إضافة تقسيم إلى نظام لم يتم التخطيط له في الأصل.
كيف تخطط TON لحل كلتا المشكلتين المذكورتين أعلاه؟
محتوى البلوكشين. سلاسل العمل.
أولاً، دعونا نتحدث عن ما تم التخطيط لتخزينه في blockchain. سيتم تخزين حالات الحسابات ("المحافظ" في الحالة الأساسية) والعقود الذكية هناك (للتبسيط، سنفترض أن هذا هو نفس الحسابات). في جوهرها، سيكون هذا جدول تجزئة عادي - المفاتيح الموجودة فيه ستكون معرفات معرف_الحسابوالقيم هي هياكل بيانات تحتوي على أشياء مثل:
- توازن؛
- رمز العقد الذكي (فقط للعقود الذكية)؛
- تخزين بيانات العقود الذكية (للعقود الذكية فقط)؛
- إحصائيات؛
- (اختياري) المفتاح العام لعمليات النقل من الحساب، افتراضيًا account_id؛
- قائمة انتظار الرسائل الصادرة (هنا يتم إدخالها لإعادة توجيهها إلى المستلم)؛
- قائمة بأحدث الرسائل التي تم تسليمها إلى هذا الحساب.
كما ذكر أعلاه، تتكون الكتل نفسها من المعاملات - الرسائل التي يتم تسليمها إلى حسابات account_id المختلفة. ومع ذلك، بالإضافة إلى account_id، تحتوي الرسائل أيضًا على حقل 32 بت Workchain_id - ما يسمى المعرف سلسلة العمل (سلسلة العمل, العمل بلوكشين). يتيح لك ذلك الحصول على العديد من سلاسل الكتل المستقلة عن بعضها البعض بتكوينات مختلفة. في هذه الحالة، تعتبر Workchain_id = 0 حالة خاصة، سلسلة عمل صفر - الأرصدة الموجودة فيه هي التي ستتوافق مع العملة المشفرة TON (Grams). على الأرجح، في البداية، لن تكون سلاسل العمل الأخرى موجودة على الإطلاق.
سلاسل تجزئة. نموذج المشاركة اللانهائية.
لكن النمو في عدد blockchain لا يتوقف عند هذا الحد. دعونا نتعامل مع التقسيم. لنتخيل أن كل حساب (account_id) يتم تخصيص blockchain خاص به - فهو يحتوي على جميع الرسائل التي تصل إليه - ويتم تخزين حالات جميع هذه blockchains على عقد منفصلة.
وبطبيعة الحال، هذا إسراف كبير: على الأرجح، في كل من هذه shardchains (com.shardchain, blockchain شارد) ستصل المعاملات نادرًا جدًا، وستكون هناك حاجة إلى الكثير من العقد القوية (بالنظر إلى المستقبل، ألاحظ أننا لا نتحدث فقط عن العملاء على الهواتف المحمولة - ولكن عن الخوادم الجادة).
لذلك، تقوم shardchain بدمج الحسابات حسب البادئات الثنائية لمعرفاتها: إذا كانت shardchain تحتوي على بادئة 0110، فسوف تتضمن المعاملات لجميع account_ids التي تبدأ بهذه الأرقام. هذا shard_prefix يمكن أن يتراوح طوله من 0 إلى 60 بت - والشيء الرئيسي هو أنه يمكن أن يتغير ديناميكيًا.
بمجرد أن تبدأ إحدى سلاسل التجزئة في تلقي عدد كبير جدًا من المعاملات، فإن العقد التي تعمل عليها، وفقًا لقواعد محددة مسبقًا، "تقسمها" إلى فرعين - ستكون بادئاتهم أطول قليلاً (وللواحد منهم ستكون هذه القطعة أطول) يساوي 0، وللآخر - 1). على سبيل المثال، shard_prefix = 0110ب سوف ينقسم إلى 01100 ب و 01101 ب. وفي المقابل، إذا بدأت سلسلتان متجاورتان تشعران بالارتياح الكافي (لبعض الوقت)، فسوف تندمجان مرة أخرى.
وبالتالي، يتم التقسيم "من الأسفل إلى الأعلى" - نفترض أن كل حساب له جزء خاص به، ولكن في الوقت الحالي يتم "لصقها معًا" بواسطة البادئات. هذا هو ما يعنيه نموذج التجزئة اللانهائي (نموذج المشاركة اللانهائية).
بشكل منفصل، أود التأكيد على أن سلاسل العمل موجودة افتراضيًا فقط - في الواقع، Workchain_id إنه جزء من معرف Shardchain محدد. من الناحية الرسمية، يتم تعريف كل Shardchain بزوج من الأرقام (Workchain_id, shard_prefix).
تصحيح الاخطاء. سلاسل الكتل العمودية.
تقليديًا، تعتبر أي معاملة تتم على blockchain بمثابة "حجر". ومع ذلك، في حالة TON، من الممكن "إعادة كتابة التاريخ" - في حالة وجود شخص ما (ما يسمى. عقدة الصياد) سيثبت أنه تم توقيع إحدى الكتل بشكل غير صحيح. في هذه الحالة، تتم إضافة كتلة تصحيح خاصة إلى سلسلة التجزئة المقابلة، والتي تحتوي على تجزئة الكتلة نفسها التي يتم تصحيحها (وليس الكتلة الأخيرة في سلسلة التجزئة). بالتفكير في Shardchain كسلسلة من الكتل الموضوعة أفقيًا، يمكننا القول أن الكتلة التصحيحية متصلة بالكتلة الخاطئة ليس من اليمين، ولكن من الأعلى - لذلك يعتبر أنها تصبح جزءًا من "بلوكشين رأسي" صغير. . وهكذا، يمكننا أن نقول أن shardchains هي blockchain ثنائي الأبعاد.
إذا تمت الإشارة، بعد كتلة خاطئة، إلى التغييرات التي تم إجراؤها من خلال الكتل اللاحقة (أي، تم إجراء معاملات جديدة بناءً على معاملات غير صالحة)، تتم إضافة المعاملات التصحيحية أيضًا إلى هذه الكتل "في الأعلى". وإذا لم تؤثر الكتل على المعلومات "المتأثرة"، فإن هذه "الموجات التصحيحية" لا تنطبق عليها. على سبيل المثال، في الرسم التوضيحي أعلاه، تم التعرف على معاملة الكتلة الأولى، التي تزيد رصيد الحساب C، على أنها غير صحيحة - لذلك، يجب أيضًا إلغاء المعاملة التي تؤدي إلى خفض رصيد هذا الحساب في الكتلة الثالثة، ويجب أيضًا إلغاء الكتلة التصحيحية يجب أن تلتزم أعلى الكتلة نفسها.
تجدر الإشارة إلى أنه على الرغم من تصوير الكتل التصحيحية على أنها موجودة "فوق" الكتل الأصلية، إلا أنها في الواقع ستتم إضافتها إلى نهاية blockchain المقابلة (حيث يجب أن تكون بتسلسل زمني). يُظهر الموقع ثنائي الأبعاد فقط النقطة التي سيتم "ربطها" بها في blockchain (من خلال تجزئة الكتلة الأصلية الموجودة فيها).
يمكنك أن تتفلسف بشكل منفصل حول مدى جودة قرار "تغيير الماضي". يبدو أننا إذا اعترفنا بإمكانية ظهور كتلة غير صحيحة في سلسلة shardchain، فلا يمكننا تجنب احتمال ظهور كتلة تصحيحية خاطئة. وهنا، بقدر ما أستطيع أن أقول، يكمن الاختلاف في عدد العقد التي يجب أن تتوصل إلى توافق في الآراء بشأن الكتل الجديدة - سيكون هناك عدد صغير نسبيًا من الأشخاص الذين يعملون على كل سلسلة تجزئة."فريق العمل» العقد (التي تغير تكوينها في كثير من الأحيان)، وسيتطلب إدخال الكتل التصحيحية موافقة الجميع عقد التحقق من الصحة. سأتحدث أكثر عن أدوات التحقق من الصحة ومجموعات العمل وأدوار العقدة الأخرى في المقالة التالية.
blockchain واحد للحكم عليهم جميعًا
هناك الكثير من المعلومات المذكورة أعلاه حول الأنواع المختلفة لسلاسل الكتل، والتي يجب أيضًا تخزينها في مكان ما. على وجه الخصوص، نحن نتحدث عن المعلومات التالية:
- وحول عدد وتكوينات سلاسل العمل؛
- حول عدد Shardchains وبادئاتها؛
- حول أي العقد مسؤولة حاليًا عن أي سلاسل تجزئة؛
- تجزئات الكتل الأخيرة المضافة إلى جميع سلاسل الأجزاء.
كما كنت قد خمنت، يتم تسجيل كل هذه الأشياء في وحدة تخزين blockchain أخرى - com.masterchain (com.masterchain, سيد blockchain). نظرًا لوجود تجزئات من كتل جميع سلاسل التجزئة في كتلها، فإنها تجعل النظام متصلًا بشكل كبير. وهذا يعني، من بين أمور أخرى، أن إنشاء كتلة جديدة في السلسلة الرئيسية سيحدث مباشرة بعد إنشاء الكتل في shardchains - من المتوقع أن تظهر الكتل في shardchains في وقت واحد تقريبًا كل 5 ثوانٍ تقريبًا، والكتلة التالية في shardchains masterchain - ثانية بعد ذلك.
ولكن من سيكون مسؤولاً عن تنفيذ كل هذا العمل الضخم - لإرسال الرسائل، وتنفيذ العقود الذكية، وتشكيل الكتل في shardchains والسلسلة الرئيسية، وحتى فحص الكتل بحثًا عن الأخطاء؟ هل سيتم تنفيذ كل هذا سرًا عن طريق هواتف ملايين المستخدمين المثبت عليها عميل Telegram؟ أو ربما يتخلى فريق دوروف عن أفكار اللامركزية وستقوم خوادمهم بذلك بالطريقة القديمة؟
في الواقع، لا هذه ولا الإجابة الأخرى صحيحة. لكن هوامش هذه المقالة تنفد بسرعة، لذلك سنتحدث عن الأدوار المختلفة للعقد (ربما لاحظت بالفعل ذكر بعضها)، وكذلك آليات عملها، في الجزء التالي.
المصدر: www.habr.com