Telegram Open Network: النظرية والتطبيق من مدقق الشبكة

في الأشهر القليلة الماضية ، تم تنشيط اهتمام مجتمع blockchain العالمي بالكامل لإطلاق واحد من أكبر مشاريع العملة المشفرة - Telegram Open Network (TON).
ما هو TON blockchain مثل حقا؟ هل شبكة TON لا مركزية حقًا؟ ما هي قابلية التوسع الحقيقي؟ كيف تصبح مدقق شبكة؟

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

في 15 نوفمبر 2019 ، انتقلت خدمات Telegram إلى testnet 2 وبدأت المرحلة الثالثة من الاختبار. واصل فريقنا المشاركة في الاختبار ، ليصبح أول مدققين على الشبكة بعد TON.

للمشاركة في عملية التحقق من الصحة ، يتعين على المستخدم ليس فقط أن يكون لديه عدد كافٍ من العملات المعدنية (الرموز GRAM) ، ولكن أيضًا عقدة شبكة كاملة تعمل باستمرار (TON Blockchain Full Node).

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

بالإضافة إلى ذلك ، نحن نريد تبادل الخبرات حول استخدام tonlib-cli ، كما لا يوجد حاليًا أي معلومات موثقة ، على عكس الإصدار الأساسي الموضح بالتفصيل في HowTo.

طن Blockchain

يتمثل المكون الرئيسي لشبكة Telegram Open Network في نظام blockchain مرن ، يشار إليه فيما بعد باسم TON Blockchain ، والذي يستطيع المطورين أنفسهم ، وفقًا للمطورين أنفسهم ، معالجة ملايين المعاملات في الثانية الواحدة ، ودعم Turing Complete Smart Contracts ، ومواصفات محدثة رسمية لـ blockchain ، تحويلات متعددة العملات ، بالإضافة إلى قنوات micropayment لشبكات الدفع خارج السلسلة (خارج السلسلة).

تعد بنية TON Blockchain فريدة من نوعها لأنها تحتوي على ميزات محددة مثل آلية blockchain العمودية "الشفاء الذاتي" و Quick Hypercube Routing ، مما يتيح أن يكون blockchain سريعًا وموثوقًا به قابلة للتطوير ومستدامة. "

كما ذكر أعلاه ، TON Blockchain هو الاسم التقليدي للشبكة اللامركزية (مجموعة من سلاسل الكتل) أو الكتل الثنائية الأبعاد ثنائية الأبعاد التي تتكون من ثلاثة أنواع رئيسية من سلاسل البلوك.

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

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

مجموعات كتل Shard أو Shardchains - مجموعة فرعية من مجموعات الرموز (تصل إلى 260) ضمن مجموعة من سلاسل العمل ، مما يضمن تشغيل نظام المشاركة وله نفس القواعد وتنسيق الكتلة كما هو الحال في سلاسل العمل. تحتوي Shardchains على مجموعة فرعية فقط من الحسابات ، اعتمادًا على البتات القليلة الأولى (الأكثر أهمية) من عنوان كل حساب معين. نظرًا لأن جميع أدوات القطع المشتركة لها شكل وقواعد مشتركة لبنات البناء ، فإن سلسلة TON blockchain في هذا الصدد متجانسة وتلبي المتطلبات الموضحة في أحد مقترحات مقياس Ethereum.



ليست كل كتلة من أجزاء shardchain (بالإضافة إلى masterchain) في الواقع مجرد كتلة ، ولكن blockchain صغيرة. كقاعدة عامة ، يتكون "block blockchain" أو "blockchain chainchain" من كتلة واحدة تمامًا ، لذلك يمكن اعتباره مجرد كتلة من سلسلة block block "العادية" (أو "سلسلة الكتلة الأفقية"). ومع ذلك ، إذا أصبح من الضروري تصحيح الكتل غير الصحيحة ، يتم إدخال كتلة جديدة في "السلسلة العمودية للكتل" ، والتي تحتوي إما على استبدال الكتل "الأفقية" الحالية ، أو "فرق الكتل" ، التي تحتوي فقط على وصف لأجزاء النسخة السابقة من الكتل التي يجب استبدالها. تُسمى هذه الآلية الخاصة بـ TON لاستبدال الكتل غير الصالحة المكتشفة دون الحاجة إلى شوكة صلبة بـ 2chain blockchain أو ببساطة 2-blockchain.

إجماع الخوارزميات وآلية حماية الشبكة

تقدم TON blockchain بناءً على نموذج Infinite Sharding (Proof of Stake أو PoS). وفقا لوثائق المطور:

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

تعتمد طريقة TON في المشاركة على مبدأ القاعدة من القاعدة إلى القمة ، مما يعني أن blockchain الأصلي قابل للتطوير بشكل كبير ، وأن كل shardchain الفردية تحتوي على حساب واحد فقط أو عقد ذكي. في المستوى التالي ، لدينا عدد كبير من "سلاسل الحسابات" ، يصف كل منها التحولات بين ولايات حساب واحد فقط ويرسل كل منهما رسائل أخرى تحتوي على معلومات حول المعاملات. في الوقت نفسه ، من غير العملي وجود مئات الملايين من المجموعات الرئيسية ، ويبدو أن التحديثات (أي كتل جديدة) في كل منها نادراً إلى حد ما ، وبالتالي ، من أجل تنفيذها بشكل أكثر فعالية ، قمنا بتجميع "سلاسل الحسابات" هذه في "مجموعات المشاركة" ، وكل مجموعة منها بشكل أساسي هي عبارة عن مجموعة من مجموعات سلاسل الحسابات التي تم ربطها بهذه الحصة المعينة. وبالتالي ، فإن "سلاسل الحسابات" هي في الواقع مجرد كتل افتراضية أو منطقية ضمن "مجموعات المشاركة" الموجودة بالفعل. تلقي هذه الآلية الضوء على العديد من قرارات التصميم الخاصة بـ TON blockchain ونطلق عليها اسم "Infinite Sharding Paradigm".

تتكون شبكة الإجماع TON من أنواع مختلفة من العقد: المدققون ، المرشحون ، المخادعون ، والمعارضون.



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

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

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

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

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

بعد ذلك ، يحتاج المصادقون إلى التوصل إلى إجماع على أساس خوارزمية BFT (بروتوكول المرونة البيزنطية) ، على غرار بروتوكول pBFT أو Honey Badger BFT . بعد ذلك ، بعد الوصول إلى الإجماع ، يتم إنشاء كتلة جديدة ، في حين يتم توزيع رسوم المعاملات بين المصادقين.

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

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

TON Testnet: تجربة عملية في Telegram Open Network

كان فريق مشروع Mercuryo مشاركًا نشطًا في شبكة الاختبار منذ سبتمبر 2019 ، وخلال فترة الاختبار اكتسبنا بعض الخبرة التي نود مشاركتها معك.

طرق الوصول إلى الشبكة

التفاعل مع شبكة TON ، بطريقة أو بأخرى ، يتلخص في استخدام مواصفات TL التي تصف كيفية التفاعل مع API. ملفات المواصفات متوفرة هنا .

هناك ثلاثة أنواع من واجهات برمجة التطبيقات:

ton_api - للتفاعل مع Full-Node Validator-engine-console
lite_api - للعمل مع العميل lite
tonlib - يتم جمع كل شيء عن المحفظة هنا وهذا هو واجهة برمجة التطبيقات الوحيدة tonlib-cli المتاحة للجمهور

إنشاء محفظة

أسهل طريقة لإنشاء محفظة هي استخدام Test Gram Wallet ، والذي يتوفر على الموقع الرسمي لأنظمة تشغيل Windows و macOS و Linux.




هناك أيضًا عدة طرق للتفاعل من خلال واجهة سطر الأوامر: الأساسية واستخدام tonlib-cli . لسوء الحظ ، في الوقت الحالي لا يوجد توافق بينهما.

سننظر هنا فقط في الأدوات التي يقدمها مطورو TON أنفسهم. إذا تم توثيق النسخة الأساسية بالتفصيل في HowTo ، فإن المعلومات عن استخدام tonlib-cli غائبة عملياً.

كما ذكر أعلاه ، في TON هناك 3 واجهات برمجة التطبيقات لمهام مختلفة. الوظائف المرتبطة بتشغيل المحفظة هي المسؤولة عن tonlib .

لبدء العمل مع tonlib-cli ، بالإضافة إلى واجهة سطر الأوامر نفسها ، يجب أن يكون لديك ملف تكوين للاتصال بخادم شبكة TON العام ، والذي يتوفر هنا .

ويتم الاتصال بها من قبل الفريق

tonlib-cli -c ton-lite-client-test1.config.json -v 0

حيث -v 0 هي المعلمة المسؤولة عن إخراج معلومات التصحيح.

قائمة الأوامر:

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

القائمة الرئيسية

يعرض أمر المفاتيح قائمة المفاتيح. لمزيد من العمليات عند تنفيذ الأوامر الأخرى ، من الضروري استخدام رقمها التسلسلي ، أي للمفتاح الأول سيكون هناك معرف 0 .

تهيئة العنوان

بعد إنشاء العنوان ، يجب تسجيله على الشبكة. للقيام بذلك ، يجب عليك أولاً تجديده. في البداية ، تم استخدام عقد ذكي خاص لهذا - testgiver ، ولكن الآن أصبح من الأسهل والأكثر ملاءمة استخدام روبوت خاص في برقية test_ton_bot .

مباشرة بعد التجديد ، يتم تعريف حالة الحساب على أنها uninited_accountState ولن تتغير إلا بعد إرسال رموز اختبار GRM من هذا العنوان.

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



يمكنك معرفة حالة المحفظة باستخدام الأمر getstate 0.



الحصول على سجل المعاملات باستخدام الأمر

gethistory <num_of_key>

حيث <num_of_key> هو رقم تسلسل المفاتيح

أساس الشبكة

كما هو الحال مع معظم سلاسل الحظر الحالية ، تعتمد TON على خوادم تقوم بتخزين محفوظات كاملة لجميع سلاسل الحظر التي تم إنشاؤها على الشبكة.

لتشغيل عقدة كاملة في شبكة اختبار TON ، تكفي 8 مراكز إنتاجية و 4 إلى 8 جيجابايت من ذاكرة الوصول العشوائي ، في وقت كتابة هذا التقرير ، كانت البيانات تشغل حوالي 50 جيجابايت من القرص الصلب ، لكن من الأفضل أن يكون لديك هامش لا يقل عن 100 جيجابايت. تجدر الإشارة إلى أنه من الأفضل استخدام محرك SSD ، كما هناك حاجة إلى عدد كبير من IOPS للتسجيل ، وإلا ستكون المزامنة مع الشبكة بطيئة للغاية.

كنظام تشغيل عامل ، من الأفضل استخدام Ubuntu 18.04 ، مثل يتم إجراء معظم اختبارات المجتمع عليها.

أدلة التثبيت

README.TXT
FullNode-HOWTO.txt
مدقق-HOWTO.txt

نظام المدقق

من المعروف أن TON blockchain يتكون من كتل shardchain و masterchain ، والتي يتم إنشاؤها والتحقق منها من خلال العقد المعينة الخاصة المسماة المصادقون. يحصل المدققون على بعض المكافآت على "عملهم": الحفاظ على صحة سلسلة TON blockchain ، بينما يتم توزيع الدخل بالتناسب داخل مجتمع المدقق.

للوهلة الأولى ، كل شيء واضح ، ولكن في الممارسة العملية ، يطرح عدد من الأسئلة فيما يتعلق بهذا:

• هل هناك قيود الشبكة على الحد الأقصى المصدق شريحة لحم؟

يمكن دائمًا التحقق من الحد الأقصى لحجم مشاركة أحد المدققين باستخدام أمر getconfig 17 ، والذي سيوضح الأحجام الفعلية لشرائح اللحم المسموح بها:



توضح لقطة الشاشة أن الحد الأدنى لحجم المشاركة في الوقت الحالي هو 10،000 GRAM. ومع ذلك ، إذا لم يحصل المدقق على أكثر من 100000 GRAM في جولة تصويت ، فلا يحق له المشاركة في الانتخابات. في الوقت نفسه ، لا يمكن أن يتجاوز الحد الأقصى لعدد الرموز لكل مدقق 10،000،000 GRAM ومن أجل إجراء التصويت ، يجب أن يتعدى الحد الأدنى لحجم شريحة اللحم الإجمالية 1،000،000 GRAM.

• كيف يتم اختيار المدققين؟

للتقدم للمشاركة في عملية التحقق من الصحة ، يجب أن يكون لديك 10،000 GRAM كحد أدنى. يتم وصف خوارزمية عملية الانتخابات بالتفصيل في العقد الذكي elector-code.fc
على الأرجح ، سيكون العقد مختلفًا في الشبكة الرئيسية ، وبالتالي فإن الإصدار الحالي ينطبق فقط على شبكة الاختبار.

لا تعني المشاركة البالغة 10،000 GRAM أنه يمكنك أن تصبح مدققًا ، مثل تلقي رموز الاختبار يمكن أن يكون آليا بسهولة عن طريق طلبات testgiver .

في الوقت الحالي ، يقوم جميع المدققين تقريبًا ، عند المشاركة في التصويت ، بتحديد الحد الأقصى للعامل بمبلغ 2.7 وشريحة لحم بمبلغ 120،000 GRAM ، نظرًا لوجود معظم هذه الرهانات ، نظرًا لوزنه ، يرتفع الحد الأدنى لشريحة اللحم إلى 120،000 / 2.7 = 45000 GRAM (على عكس 100،000 وفقا للوثائق الرسمية). ولكن حتى مع وجود الحد الأدنى من هذه الشريحة من شرائح اللحم ، فإن فرصك تكون صفرًا تقريبًا ، نظرًا لأن المعيِّنين الثلاثة الأوائل لديهم عامل أقصى يبلغ 2 ، مما يرفع الحد الأدنى للحصة إلى 60،000 GRAM ، مما يتيح لك أن تصبح مدققًا في testnet.

إذا زادت جميع أجهزة التحقق الحالية من عاملها الأقصى أو قللت حجم شريحة اللحم ، فسيكون من الممكن أن تصبح جهة تحقق مع أقل شريحة لحم ، بالنظر إلى أنه لن يتم تجاوز الحد الأقصى لعدد أجهزة التحقق (1000 عقدة).

• إذا كان نظام المدقق مركزيا ، ثم blockchain كله أيضا؟

لا توجد شيكات ، أي لا أحد يتحكم مركزياً في المدققين ؛ المرشحون أنفسهم يحددون المخاطر عند اختيار المدقق.

• ما هي أنواع الغرامات المقدمة للمدققين؟

لا توجد معلومات في الوقت الحالي ، على الأرجح ستكون هناك آلية توافق في الوثيقة ، لأنه حتى العقد خارج المزامنة حصلت على جوائز في testnet.

• العقود الذكية

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

أثناء الاختبار ، كان من الممكن معرفة أن قاعدة كود FunC ليست ضخمة جدًا (مقارنةً بـ Fift ) وتتيح لك معرفة ذلك بشكل أسرع كثيرًا ، لذا فإن العمل مع FunC أسهل كثيرًا من Fift .

• الأسئلة الفعلية / العاجلة / المفتوحة

تزامن بطيء
https://github.com/ton-blockchain/ton/issues/100

أذونات محرك التحقق من الصحة
+0 = استفسارات العملاء المعتادة
+1 = استعلامات إحصائيات العقدة الكاملة
+2 = استعلامات تعديل تكوين الكود الكامل
+4 = استعلامات يحتمل أن تكون خطرة (مثل تصدير المفتاح الخاص أو توقيع سلاسل تعسفية)
+8 = محفوظة للإضافات المستقبلية (لا تفعل شيئًا في الوقت الحالي)

• كيفية جعل PIPE يعمل مع العميل الخفيف؟

بشكل افتراضي ، يتم إرسال إخراج lite-client إلى stderr ، لذا يتعين عليك أولاً إعادة توجيه الإخراج من stderr إلى stdout:

$ لايت العميل 2 >> (grep ...)

• ما هي الخيارات للوصول إلى الشبكة البرنامجية؟

https://github.com/ton-blockchain/ton/issues/76

• ما تكوين الخادم المطلوب للمدقق؟

يوصى رسميًا باستخدام خادم المعالج المزدوج (على الأقل 8 مراكز لكل معالج). البرنامج لا يتطلب الكثير على ذاكرة الوصول العشوائي ، لذلك 16 جيجا بايت كافية. يجب استخدام SSD كمحرك أساسي ، وهو الحد الأدنى الموصى به للحجم وهو 512 جيجابايت. محرك الأقراص الصلبة 8 تيرابايت يكفي لتخزين البيانات المؤرشفة.

من الضروري أن يكون لديك اتصال إنترنت فائق السرعة: فمع متوسط ​​حمل متوقع يبلغ 100 ميجابت / ثانية ، يجب أن تكون قادرًا على التعامل مع أحمال الذروة التي تصل إلى 1 جيجابت / ثانية.

يوصى باستخدام XFS كنظام ملفات ، حيث يتم تخزين المعلومات حول كل كتلة في ملف منفصل. من المعروف ، على سبيل المثال ، ext4 لا يعمل بشكل جيد للغاية مع عدد كبير من الملفات الصغيرة ويمكن أن يؤدي إلى موقف حيث ببساطة ليس لديك inodes حرة مع مساحة كافية على القرص.

• كيف أعرف أن العقدة متزامنة؟

سيكمل السجل رسالة المزامنة ، أو يجب أن يكون استخدام برنامج "getstats" الخاص بـ Validator -engine-console -c unixtime و masterchainblocktime هو نفسه تقريبًا.

• كم من المدققين يمكن أن يكون على الانترنت؟

Getconfig 16
max_validators: 1000 max_main_validators: 100 min_validators: 5

• كيفية معرفة المدققين النشطين الحاليين؟

Getconfig 34

السابقة getconfig 32 مجموعة المصادقة

• الوقت الذي يتم اختيار المدققين؟

تشير الورقة البيضاء إلى أنه يتم اختيار أجهزة التحقق من الصحة لمدة شهر ، ولكن في testnet هذه المرة أقل بكثير ويمكنك العثور عليها من تكوين getconfig 15.

بعد إعادة تشغيل testnet ، تغيرت الفواصل الزمنية للمدققين:

ConfigParam (15) = (validators_elected_for: 65536 الانتخابات_start_before: 32768 الانتخابات_end_before: 8192 share_held_for: 32768)

من خلالها ، يتم تحديد مجموعة من أجهزة التحقق من الصحة لمدة 65536 ثانية.

• ?

Validator-HOWTO . -, getconfig 1 . .



result: [ 0 ], , timestamp, . , :

> runmethod -1:A4C2C7C05B093D470DE2316DBA089FA0DD775FD9B1EBFC9DC9D04B498D3A2DDA participant_list

• TON?

على الرغم من التصميم المعقد لمكدس الشبكة المستند إلى شبكات التراكب ، لا يزال UDP و TCP يستخدمان كبروتوكولات نقل TON. من المعروف أن أقفال Telegram اليوم غير ناجحة ، لأن من الممكن تغيير عناوين IP ، واستخدام الوكلاء وتحديث الإعدادات من خلال الدفع. ومع ذلك ، لن تتاح TON لمثل هذه الفرص: ليس من الممكن تحريك العقد بسرعة ، بينما لن يرغب المدققون في المخاطرة بحصصهم. لذلك ، على الأرجح ، في المستقبل القريب ، سيقدم مطورو Telegram حلولًا جديدة لتجاوز الأقفال ، على سبيل المثال ، باستخدام وكيل ADNL.

فيما يلي حركة مرور عقدة واحدة كاملة بعد معالجة 10 ملايين حزمة. قائمة عناوين IP 159 تشغيل العقد testnet كاملة كما يلي:

126 DIGITAL OCEAN ( TON)
13 AMAZON
4 GOOGLE
3 HETZNER
3 ALIBABA CLOUD
2 OVH
2 SELECTEL
2 ONLINE.NET
1 LINODE
1 hosteurope.de
1 contabo.de
and 1 person possibly hosting it at home in Italy telecomitalia.it

IP- . , TON, -.

, Telegram Open Network WEB 3.0 , Telegram.

TON , « », . , :

• , ;
• - (Fift FunC), ;
• , ;
• telegram-, TON;

TON

(Infinite Sharding Paradigm) , , .. , , , , , , . TON , « » . , , TON .

, , TON , , « » , , , .

, , TON ( Gram). , , , TON PoS, , -.

PoS . , - , PoS , . PoS, , . , PoS , .

Grams Wallet — Gram

- TON Grams Wallet , Telegram, - , Telegram FZ-LLC ( ).

, , , , , 18 , , , , Telegram FZ-LLC .

, , (. Linux). , (. 4, . 4.3), , Telegram Open Network:

« TON Blockchain ».

Our open source

Go-binding library

, TON TONLIB.

Mercuryo Go, , -, .
https://github.com/mercuryoio/tonlib-go

tonlib api , , :

• (//// );
• /gram/boc- ;
• الحصول على حالة المحفظة ومعلومات عنها ؛
• الحصول على قائمة المعاملات عن طريق المحفظة ؛
• تونغو هو محفظة فائدة خفيفة الوزن.

في الوقت الحالي ، الأولوية في تطوير المكتبة هي:

• مراقبة الشبكة. القدرة على تلقي المعلومات على كل معاملة من جميع كتل الشبكة. نحن نتطلع حقًا إلى الدعم من tonlib نفسه ؛
• التفاعلات مع العقود. العمل جار بالفعل
• تمديد وظيفة مساعد وحدة التحكم في tongo. نحن نحاول إضافة شيء جديد مع كل إصدار ؛
• إنشاء هياكل الواجهة وفقًا لمواصفات tl. سيتيح لنا أن نكون أكثر تنقلًا وإصدار تحديثات بأقل قدر من التأخير ؛

سنواصل سلسلة من المنشورات حول اختبار Telegram Open Network و Grams Wallet وسنشارك ملاحظاتنا.