سلام، زه د DRD KP پروژې په ټیم کې کار کوم (د ویل سیټونو د ژوند دورې څارنې لپاره د ډیټا راجسټری ویشل). دلته زه غواړم د ټیکنالوژۍ محدودیتونو لاندې د دې پروژې لپاره د شرکت بلاکچین رامینځته کولو کې زموږ د ټیم تجربه شریک کړم. زه به اکثرا د هایپرلیجر فابریک په اړه وغږیږم ، مګر دلته تشریح شوي چلند هر اجازه لرونکي بلاکچین ته لیږدول کیدی شي. زموږ د څیړنې وروستی هدف د سوداګرۍ بلاکچین حلونو چمتو کول دي ترڅو وروستی محصول د کارولو لپاره خوندور وي او ساتل یې خورا ستونزمن ندي.
دلته به هیڅ کشف ، غیر متوقع حلونه شتون ونلري ، او هیڅ ځانګړي پرمختګونه به دلته روښانه نشي (ځکه چې زه هیڅ نلرم). زه یوازې غواړم خپل معتدل تجربه شریکه کړم، وښایه چې "دا ممکنه وه" او شاید، په تبصرو کې د ښه او نه ښه پریکړې کولو په اړه د نورو خلکو تجربو په اړه ولولئ.
ستونزه: بلاکچین لا تر اوسه اندازه نه کوي
نن ورځ ، د ډیری پراختیا کونکو هڅو هدف د بلاکچین واقعیا مناسب ټیکنالوژي رامینځته کول دي ، نه په ښکلي ریپر کې د وخت بم. دولتي چینلونه، خوشبین رول اپ، پلازما او شارډینګ به شاید عام شي. یوه ورځ. یا شاید TON به بیا لانچ د شپږو میاشتو لپاره وځنډوي، او راتلونکی پلازما ګروپ به شتون ولري. موږ کولی شو په راتلونکي سړک نقشه باور ولرو او د شپې په زړه پوري سپینې کاغذونه ولولو ، مګر دلته او اوس موږ اړتیا لرو د هغه څه سره یو څه وکړو چې موږ یې لرو. خندا سرته ورسوئ.
په اوسنۍ پروژه کې زموږ د ټیم لپاره ټاکل شوې دنده په عمومي ډول داسې ښکاري: ډیری مضامین شتون لري، څو زرو ته رسیږي، څوک چې نه غواړي د باور په اړه اړیکې رامینځته کړي؛ دا اړینه ده چې په DLT کې یو حل رامینځته کړئ چې په عادي کمپیوټرونو کې به د ځانګړي فعالیت اړتیاو پرته کار وکړي او د کارونکي تجربه چمتو کړي چې د مرکزي محاسبې سیسټمونو څخه بد نه وي. د حل ترشا ټیکنالوژي باید د معلوماتو د ناوړه لاسوهنې احتمال کم کړي - له همدې امله بلاکچین دلته دی.
د سپینو کاغذونو او رسنیو څخه شعارونه موږ سره ژمنه کوي چې راتلونکی پرمختګ به موږ ته اجازه راکړو چې په هره ثانیه کې ملیونونه راکړه ورکړه وکړو. دا واقعا څه شی دی؟
Mainnet Ethereum اوس مهال په ~ 30 tps روان دی. یوازې د دې له امله، دا ستونزمنه ده چې دا د بلاکچین په توګه د هر ډول کارپوریټ اړتیاو لپاره مناسب وي. د اجازه ورکړل شوي حلونو په مینځ کې معیارونه شتون لري چې 2000 tps ښیې () یا 3000 tps (، په خپرونه کې لږ څه شتون لري ، مګر تاسو اړتیا لرئ په پام کې ونیسئ چې بنچمارک په زاړه توافق انجن کې ترسره شوی و). وه ، کوم چې ترټولو خرابې پایلې نه دي ورکړي، 20000 tps، مګر تر دې دمه دا یوازې اکادمیک څیړنه ده، د دې باثباته پلي کولو په تمه. دا امکان نلري چې یو شرکت چې د بلاکچین پراختیا کونکو ډیپارټمنټ ساتلو توان لري د ورته شاخصونو سره مخ شي. مګر ستونزه یوازې د ټرپټ نه ده، ځنډ هم شتون لري.
لطیسي
د هغه وخت څخه ځنډ چې معامله د سیسټم لخوا د هغې وروستي تصویب ته پیل کیږي نه یوازې په سرعت پورې اړه لري چې پیغام د اعتبار او ترتیب له ټولو مرحلو څخه تیریږي بلکه د بلاک جوړونې پیرامیټونو پورې هم اړه لري. حتی که زموږ بلاکچین موږ ته اجازه راکوي چې د 1000000 tps په سرعت سره ژمنې وکړو، مګر د 10 MB بلاک تولید لپاره 488 دقیقو ته اړتیا لري، ایا دا به زموږ لپاره اسانه شي؟
راځئ چې په هایپرلیجر فابریک کې د لیږد ژوند دورې ته نږدې وګورو ترڅو پوه شو چې وخت چیرې مصرف کیږي او دا څنګه د بلاک تولید پیرامیټونو سره تړاو لري.
له دې ځایه اخیستل شوی:
(1) پیرودونکی یوه معامله رامینځته کوي ، د تایید همکارانو ته یې لیږي ، وروستنۍ معامله سمول کوي (د چین کوډ لخوا رامینځته شوي بدلونونه اوسني حالت ته پلي کوي ، مګر لیجر ته ژمن مه کوئ) او RWSet ترلاسه کوي - کلیدي نومونه ، نسخې او ارزښتونه په CouchDB کې د راټولولو څخه اخیستل شوي، (2) تایید کونکي پیرودونکي ته یو لاسلیک شوی RWSet بیرته لیږي، (3) پیرودونکی یا د ټولو اړینو همکارانو لاسلیکونو شتون چک کوي (تحقیق کونکي)، او بیا لیږد د امر کولو خدمت ته لیږي. ، یا دا د تایید پرته لیږي (چیک به بیا هم وروسته ترسره شي) ، د امر کولو خدمت یو بلاک رامینځته کوي او (4) بیرته ټولو همکارانو ته لیږي ، نه یوازې ملاتړ کونکي؛ ملګري ګوري چې د لوستل شوي سیټ کلیدي نسخې د ډیټابیس نسخو سره سمون لري، چې ټول ملاتړ کونکي لاسلیکونه لري، او په پای کې د بلاک ژمنه کوي.
مګر دا ټول نه دي. د "آرډر یو بلاک جوړوي" کلمې نه یوازې د راکړې ورکړې ترتیب پټوي، بلکې د مشر څخه پیروانو ته د 3 ترتیبي شبکې غوښتنې هم پټوي: مشر لاګ ته پیغام اضافه کوي، پیروانو ته یې لیږي، وروستی یې زیاتوي. د دوی لاګ ته، مشر ته د بریالي نقل تصدیق لیږي، مشر پیغام ورکوي، پیروانو ته د ژمنې تصدیق لیږي، پیروان ژمن دي. هرڅومره چې د بلاک جوړیدو اندازه او وخت کوچنی وي ، هومره ډیر ځله د ترتیب کولو خدمت باید توافق رامینځته کړي. Hyperledger Fabric د بلاک جوړولو لپاره دوه پیرامیټونه لري: BatchTimeout - د بلاک جوړیدو وخت او د BatchSize - د بلاک اندازه (د معاملو شمیر او پخپله د بلاک اندازه په بایټ کې). هرڅومره ژر چې د پیرامیټونو څخه یو حد ته ورسیږي ، یو نوی بلاک خوشې کیږي. هرڅومره چې نور نوډونه ترتیب کړي ، دا به ډیر وخت ونیسي. له همدې امله، تاسو اړتیا لرئ د BatchTimeout او BatchSize زیات کړئ. مګر څرنګه چې RWSets نسخه شوي، څومره لوی بلاک چې موږ یې جوړوو، د MVCC شخړو احتمال لوړ دی. برسېره پردې، لکه څنګه چې د BatchTimeout زیاتوالی راځي، UX په ناورین سره خرابیږي. د دې ستونزو د حل لپاره لاندې سکیم زما لپاره معقول او څرګند ښکاري.
څنګه د بلاک نهایی کیدو لپاره د انتظار څخه مخنیوی وکړئ او د لیږد حالت تعقیب کولو وړتیا له لاسه مه ورکوئ
هرڅومره چې د جوړیدو وخت او د بلاک اندازه اوږد وي ، د بلاکچین له لارې لوړوالی. یو له بل څخه په مستقیم ډول تعقیب نه کوي، مګر دا باید په یاد ولرئ چې په RAFT کې د اجماع رامینځته کول د مشر څخه پیروانو او شاته درې شبکې غوښتنې ته اړتیا لري. هرڅومره چې نور نوډونه ترتیب کړي ، دا به ډیر وخت ونیسي. هرڅومره چې د بلاک جوړیدو اندازه او وخت کوچنی وي ، هومره ورته تعاملات شتون لري. څنګه د وروستي کارونکي لپاره د سیسټم غبرګون وخت زیاتولو پرته د نسل وخت او بلاک اندازه زیاته کړئ؟
لومړی، موږ اړتیا لرو چې په یو ډول د MVCC شخړې حل کړو چې د لوی بلاک اندازې له امله رامینځته شوي، کوم چې ممکن د ورته نسخې سره مختلف RWSets شامل کړي. په ښکاره ډول ، د پیرودونکي اړخ کې (د بلاکچین شبکې په تړاو ، دا کیدی شي شاته وي ، او زما مطلب دا دی) تاسو اړتیا لرئ د MVCC شخړې سمبالونکی، کوم چې کیدی شي یو جلا خدمت وي یا د کال څخه پورته یو منظم سینګار کونکی وي چې د بیا هڅه کولو منطق سره معامله پیل کوي.
بیا هڅه کول د اضطراري ستراتیژۍ سره پلي کیدی شي ، مګر بیا ځنډ به د ګړندي کیدو په څیر خراب شي. نو تاسو باید په ټاکلي کوچني محدودیتونو کې تصادفي بیا هڅه وکاروئ ، یا یو ثابت. په لومړي اختیار کې د احتمالي ټکرونو په نظر کې نیولو سره.
بل ګام دا دی چې د سیسټم سره د پیرودونکي تعامل غیر متناسب کړئ ترڅو دا د 15، 30 یا 10000000 ثانیو لپاره انتظار ونه کړي، کوم چې موږ به د BatchTimeout په توګه تنظیم کړو. مګر په ورته وخت کې، دا اړینه ده چې د دې تصدیق کولو وړتیا وساتو چې د لیږد لخوا پیل شوي بدلونونه په بلاکچین کې ثبت شوي نه دي.
ډیټابیس د لیږد حالت ذخیره کولو لپاره کارول کیدی شي. ترټولو ساده اختیار د CouchDB دی د دې د کارولو اسانتیا له امله: ډیټابیس د بکس څخه بهر یو UI لري، یو REST API، او تاسو کولی شئ په اسانۍ سره د هغې لپاره نقل او شارډینګ تنظیم کړئ. تاسو کولی شئ په ساده ډول په ورته CouchDB مثال کې یو جلا ټولګه رامینځته کړئ چې د دې نړۍ حالت ذخیره کولو لپاره فیبریک کاروي. موږ باید دا ډول اسناد ذخیره کړو.
{
Status string // Статус транзакции: "pending", "done", "failed"
TxID: string // ID транзакции
Error: string // optional, сообщение об ошибке
}دا سند ډیټابیس ته لیکل کیږي مخکې لدې چې معامله شریکانو ته واستول شي ، د ادارې ID کارونکي ته بیرته راستون کیږي (هغه ID د کیلي په توګه کارول کیږي) که دا د رامینځته کولو عملیات وي ، او بیا د حالت ، TxID او خطا ساحې دي. تازه شوي لکه څنګه چې اړونده معلومات د همکارانو څخه ترلاسه کیږي.
په دې سکیم کې، کاروونکي په پای کې د بلاک جوړیدو ته انتظار نه کوي، د 10 ثانیو لپاره په سکرین کې د څرخیدو څرخ ګوري، هغه د سیسټم څخه سمدستي ځواب ترلاسه کوي او کار ته دوام ورکوي.
موږ د لیږد حالتونو ذخیره کولو لپاره BoltDB غوره کړی ځکه چې موږ اړتیا لرو حافظه خوندي کړو او نه غواړو د جلا ډیټابیس سرور سره د شبکې متقابل عمل وخت ضایع کړو ، په ځانګړي توګه کله چې دا تعامل د ساده متن پروتوکول په کارولو سره پیښیږي. په هرصورت، که تاسو CouchDB د پورته ذکر شوي سکیم پلي کولو لپاره کاروئ یا په ساده ډول د نړۍ حالت ذخیره کولو لپاره، په هر حالت کې دا معنی لري چې په CouchDB کې د معلوماتو ذخیره کولو طریقه غوره کړئ. په ډیفالټ ، په CouchDB کې ، د b-tree نوډونو اندازه 1279 بایټس ده ، کوم چې په ډیسک کې د سکتور اندازې څخه خورا کوچنی دی ، پدې معنی چې د ونې لوستل او بیا توازن دواړه به ډیسک ته ډیر فزیکي لاسرسي ته اړتیا ولري. مطلوب اندازه د معیار سره مطابقت لري او 4 کیلوبایټ دی. د اصلاح کولو لپاره موږ باید پیرامیټر تنظیم کړو د btree_chunk_size مساوي 4096 د CouchDB ترتیب کولو فایل کې. د BoltDB لپاره دا ډول لاسي مداخله .
شاته فشار: د بفر ستراتیژي
مګر ډیر پیغامونه کیدی شي. د سیسټم څخه ډیر څه چې اداره کولی شي ، د ډیاګرام کې ښودل شوي سربیره د لسګونو نورو خدماتو سره سرچینې شریکول - او دا ټول باید په بې عیب ډول کار وکړي حتی په ماشینونو کې چې د Intellij Idea چلول به خورا ستړي وي.
د مخابراتو سیسټمونو، تولیدونکي او مصرف کونکي مختلف ظرفیت ستونزه په بیلابیلو لارو حل کیږي. راځئ وګورو چې موږ څه کولی شو.
غورځول: موږ کولی شو ادعا وکړو چې موږ په T ثانیو کې د ډیرو X لیږدونو پروسس کولو توان لرو. ټولې غوښتنې چې له دې حد څخه تیریږي رد کیږي. دا خورا ساده دی، مګر بیا تاسو کولی شئ د UX په اړه هیر کړئ.
کنټرول کول: مصرف کونکی باید یو ډول انٹرفیس ولري چې له لارې یې د بار پورې اړه لري، هغه کولی شي د تولید کونکي TPS کنټرول کړي. بد ندی ، مګر دا د پیرودونکي پراختیا کونکو باندې مکلفیتونه وضع کوي چې د دې انٹرفیس پلي کولو لپاره بار رامینځته کوي. دا زموږ لپاره د منلو وړ نه دی، ځکه چې بلاکچین به په راتلونکي کې په لوی شمیر کې د اوږدې مودې سیسټمونو سره مدغم شي.
بفر کول: د دې پرځای چې د ان پټ ډیټا جریان سره مقاومت وکړو ، موږ کولی شو دا جریان بفر کړو او په اړین سرعت یې پروسس کړو. په ښکاره ډول دا غوره حل دی که موږ غواړو د کارونکي ښه تجربه چمتو کړو. موږ په RabbitMQ کې د قطار په کارولو سره بفر پلي کړ.
په سکیم کې دوه نوي عملونه اضافه شوي: (1) وروسته له دې چې API ته غوښتنه راشي ، د لیږد زنګ وهلو لپاره اړین پیرامیټرو سره یو پیغام په کتار کې ځای په ځای شوی ، او پیرودونکي یو پیغام ترلاسه کوي چې معامله یې منل شوې ده. سیسټم، (2) بیکینډ د قطار څخه په ترتیب کې ټاکل شوي سرعت سره ډاټا لوستل کوي؛ معامله پیل کوي او د وضعیت پلورنځي کې ډیټا تازه کوي.
اوس تاسو کولی شئ د جوړیدو وخت ډیر کړئ او څومره چې تاسو غواړئ ظرفیت بلاک کړئ ، د کارونکي څخه ځنډونه پټ کړئ.
نور وسایل
دلته د چین کوډ په اړه هیڅ ندي ویل شوي ، ځکه چې د یوې قاعدې په توګه ، پدې کې د مطلوب کولو لپاره هیڅ شتون نلري. چینکوډ باید د امکان تر حده ساده او خوندي وي - دا ټول هغه څه دي چې ورته اړتیا لري. چوکاټ موږ سره په ساده او خوندي ډول د چین کوډ لیکلو کې مرسته کوي د S7 Techlab او جامد تحلیل کونکي څخه .
سربیره پردې، زموږ ټیم د اسانتیاوو سیټ رامینځته کوي ترڅو د فابریک سره کار ساده او خوندور کړي: لپاره یو ګټورتیا (د سازمانونو اضافه کول / لیرې کول، RAFT نوډونه)، د دې لپاره کارول . که تاسو غواړئ مرسته وکړئ، تاسو ته ښه راغلاست.
پایلې
دا طریقه تاسو ته اجازه درکوي په اسانۍ سره د هایپرلیجر فابریک د کورم سره ځای په ځای کړئ، د نورو خصوصي ایتیروم شبکې (PoA یا حتی PoW)، د پام وړ ریښتیني ټروپټ کم کړئ، مګر په ورته وخت کې نورمال UX وساتئ (دواړه په براوزر کې د کاروونکو لپاره او د مدغم سیسټمونو لپاره). کله چې په سکیم کې د ایتیریم سره فیبریک ځای په ځای کړئ، تاسو به یوازې د MVCC شخړو پروسس کولو څخه د اټومي غیر زیاتوالي او بیا لیږلو ته د بیاکتنې خدمت / سینګار کونکي منطق بدلولو ته اړتیا ولرئ. بفرینګ او د وضعیت ذخیره دا ممکنه کړې چې د بلاک جوړیدو وخت څخه د غبرګون وخت دوه چنده کړي. اوس تاسو کولی شئ په زرګونو آرډر نوډونه اضافه کړئ او ویره مه کوئ چې بلاکونه ډیری وختونه رامینځته کیږي او د ترتیب کولو خدمت بار کړئ.
اساسا، دا ټول هغه څه دي چې ما غوښتل شریک کړم. زه به خوښ شم که دا د یو چا سره د دوی په کار کې مرسته وکړي.
سرچینه: www.habr.com