تشریح کامل پروتکل لیسک

این مقاله به تشریح کامل ساختار پروتکل یکی از پیشتازان پلتفرم های بلاکچینی می‌پردازد. لیسک با عرضه اپلیکیشن‌های بلاکچینی قصد دارد تا گامی دیگر در عرصه فناوری بلاکچین بردارد. اما تفاوت در اینجاست که لیسک دست به ساختن توکن‌هایی با نام خود زده و به این ترتیب تعامل و داد و ستد را همزمان در دنیای ارزهای رمزنگاری‌شده پایه ریزی کرده است. در سیستم لیسک، بلاک‌های جدید توسط نمایندگان به بلاکچین افزوده می‌شود. نماینده ها در این سیستم با یک فرایند کاملا دموکراتیک انتخاب می‌شوند. در این مقاله شما درس‌های مهمی درمورد لیسک خواهید آموخت، بخش مستندسازی و پرسش‌های متداول (FAQ) در اختیار شماست تا کار خود را هر چه زودتر با لیسک آغاز کنید. اگر نیاز به اطلاعات و راهنمایی‌های بیشتری دارید، منابع دیگری نیز در دسترس هستند.

0 163

لیسک چیست؟

لیسک یک ارز رمزنگاری ‌شده است که پلتفرم نسل بعدی بلاکچین ها را در اختیار شما قرار می‌دهد و بستری را برای توسعه و توزیع اپلیکیشن‌های بلاکچینی با پایه جاوااسکریپت (JavaScript) فراهم می‌کند. لیسک راه آسوده‌ای را برای استفاده از رابط‌کاربری و همچنین امکان بهره‌مندی از تمام مزایا و ویژگی‌های اکوسیستم در اختیار کاربران قرار می‌دهد. توسعه‌دهندگان می‌توانند از طریق لیسک اپلیکیشن‌های خود را بسازند و آن ها را منتشر و توزیع کرده و آن‌ها را به مرحله درآمدزایی برسانند. این کار در یک سیستم تقویت‌شده با ارز رمزنگاری ‌شده انجام می‌گیرد که استفاده از بلاکچین‌های سفارشی، قراردادهای هوشمند، ظرفیت ذخیره‌سازی در فضای ابری و نودهای محاسباتی را تسهیل می‌کند.

توکن‌های لیسک

تمام ارزهای رمزنگاری شده از توکن‌ها برای خلق یک سیستم بهره‌ور ایمن استفاده می‌کنند. به این ترتیب، لیسک نیز یک توکن رمزنگاری‌شده را با نام LSK عرضه کرده است. با این توکن قیمت‌های گوناگون پیشنهادات معاملاتی پرداخت می‌شود و استفاده از سیستم میسر می‎گردد. توکن‌های LSK به روش‌های مختلفی به دست می‌آیند، مثلا می‌توان آن‌ها را از یک صرافی یا از یک شخص دیگر با استفاده از ارز فیات یا بیت‌کوین (BTC) خریداری کرد.

پس‌زمینه فنی

لیسک به عنوان یک نرم‌افزار از سه جز اصلی کد جاوا اسکریپت، موتور محاسباتی NodeJS و دیتابیس و حافظه ذخیره‌سازی PostgreSQL تشکیل شده است.

جاوا اسکریپت

بدون شک جاوا اسکریپت زبان اینترنت است. تقریبا تمام سایت‌های موجود در اینترنت به نوعی از جاوا اسکریپت استفاده می‌کنند که قابلیت‌های زیادی برای کاربران عرضه می‌کند. درست به همین دلیل، لیسک با زبان جاوا اسکریپت نوشته شده است، ناگفته نماند که توسعه‌دهندگان دسترسی بالایی به این زبان برنامه‌نویسی دارند. یک کاربر تقریبا با استفاده از تمام جستجوگرها می‌تواند کدهای جاوااسکریپت را بنویسد و آن‌ها را تست کند و با توجه به این که لیسک قصد دارد طلایه‌دار پلتفرم اپلیکیشن‌های بلاکچینی باشد، باید از زبانی استفاده کند که قابلیت اجرا کردن در تمام رایانه‌های رومیزی را داشته باشد.

NodeJS

لیسک از NodeJS به عنوان موتور محاسباتی beckend کدهای جاوااسکریپت استفاده می‌کند. NodeJS به خودی خود انعطاف‌پذیری بالایی دارد و می‌توان از آن در تمام ساختارهای رومیزی و بسیاری از ابزارهای IoT (اینترنت اشیا) بهره‌مند شد. همین انعطاف‌پذیری به لیسک قابلیت اجرا شدن را در تمام وسایلی می‌دهد، که دارای سخت‌افزاری با قابلیت پشتیبانی از کلایِنت (client) هستند.

PostgreSQL

تمام بلاکچین‌ها داده‌ها را به شیوه‌های مختلفی نگهداری می‌کنند، برخی از آن‌ها از SQLite بهره می‌برند، در حالی که بقیه از LevelDB بهره‌مند می‌شوند. این‌ سلوشن‌ها (solution) به خوبی در سلوشن‌های بلاکچینی خالص جواب می‌دهند، اما از ویژگی‌های قدرتمندانه PosgreSQL در آن‌ها خبری نیست.

PostgreSQL یکی از قدیمی‌ترین سیستم‌های دیتابیس منطقی متن‌باز است. با این سیستم، کاربر می‌تواند انواع و اقسام مختلف اطلاعات، از فایل‌های باینری (binary) گرفته تا حتی فایل‌های موسیقی را ذخیره کند. همین قابلیت است که PostgreSQL را تبدیل به مناسب‌ترین گزینه‌ برای سیستم لیسک می‌کند و موتور دیتابیس لازم را برای پشتیبانی از اپلیکیشن‌های بلاکچینی فراهم می‌سازد. علاوه بر این ویژگی‌ها، قابلیت پشتیبان گیری و تحمل خطا (fault tolerance) در Postgres آن را در دنیای دیتابیس‌های متن باز بی‌رقیب می‌سازد.

بلاک ها

یک بلاکچین از چندین بلاک‌ تشکیل شده است و خود بلاک از یک هدر (header) و یک فهرست از تراکنش‌های تأییدشده تشکیل می‌شود. وقتی یک اسلات (slot) به یک نماینده (delegate) تخصیص داده شود که نود (node) آن در حال اجرا شدن است، این نماینده، بلاک بعدی را تولید می‌کند و 25 تراکنش را از استخر تراکنش (transaction pool) تأیید می‌نماید. این تراکنش‌های تأییدشده به پی‌لود (payload) بلاک مربوطه اضافه خواهد شد و متعاقبا وارد آن بلاک می‌شود.

هدر بلاک

هِدر بلاک دربردارنده تمام اطلاعات مربوط به بلاک است. یک هدر بلاک از فیلدهای (field) زیر تشکیل می‌شود:

  • فیلد 32 بیتی صحیح مشخص‌کننده نسخه بلاک
  • فیلد 32 بیتی مهرزمانی (epoch timestamp) که زمان درست شدن بلاک را مشخص می‌کند
  • فیلد 64 بیتی شناسه بلاک قبلی
  • فیلد 64 بیتی صحیح نمایانگر تعداد تراکنش‌هایی که در بلاک پردازش می‌شود
  • فیلد 64 بیتی صحیح مربوط به مقدار کل لیسک‌های انتقال داده شده
  • فیلد 64 بیتی صحیح مربوط به مقدار کل هزینه‌های مربوط به بلاک
  • فیلد 64 بیتی صحیح مربوط به پاداش لیسک برای نماینده مربوطه
  • فیلد 32 بیتی صحیح برای طول پی‌لود
  • فیلد 256 بیتی هش (hash) پی‌لود
  • فیلد 256 بیتی حاوی کلید عمومی (public ley) نماینده ای که این بلاک را درست کرده است.

کدهای زیر نمودار ساختار کامل یک هدر بلاک است:

Block-Header

{

“id”: “15787022670460703397”,

“version”: 0,

“timestamp”: 23039010,

“height”: 1574052,

“previousBlock”: “4576781903037947065”,

“numberOfTransactions”: 0,

“totalAmount”: 0,

“totalFee”: 0,

“reward”: 500000000,

“payloadLength”: 0,

“payloadHash”: “e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855”,

“generatorPublicKey”: “c0ab189f5a4746725415b17f8092edd3c266d1e758e840f02a3c99547b3a527f”,

“blockSignature”: “c6b2bcc960066be078efbfffed625f61553a7bc18ebde3892636c2f36850de234a9c70ba3e33b606db2eff724398026984e4d391c1fbbe70c94dd9d07ff0060b”,

“totalForged”: “500000000”

}

روند وارد کردن هدر بلاک درست مانند روند وارد کردن یک تراکنش است. یک هش sha-256 از هدر بلاک تولید می‌شود و با استفاده از رمز مخصوص نماینده مربوطه وارد می‌شود. همین که هدر بلاک وارد شد، سیستم شناسه بلاک را درست مانند تراکنش‌ها می‌سازد. هدر بلاکی که کامل شده است، با استفاده از SHA-256 هش‌گذاری می‌شود و 8 بیت نخست از هش، از آخر به اول، به عنوان شناسه بلاک استفاده می‌شود.

یک بلاک واردشده شناسه بلاک را به طریقه زیر تولید می‌کند:

پی‌لود بلاک

پی‌لود بلاک از 25 تراکنش تاییدنشده تشکیل می‌شود که پس از امضا شدن بلاک شکل می‌گیرند. بیشینه تعداد تراکنش‌های در دسترسی که پی‌لود در برمی‌گیرد، همین مقدار را خواهد داشت، به شرطی که تراکنش‌های پی‌لود از مقدار بیشینه هر نوع تراکنش تجاوز نکند.

مقدار بیشنه تراکنش برحسب نوع آن مطابق با جدول زیر است.

نوع تراکنش

بیشینه اندازه (بر حسب بایت)

Type 0 220
Type 1 149
Type 2 201
Type 3 2,326
Type 4 1,223

اگر همه تراکنش‌ها از نوع سوم (Type3) باشند، آنگاه اندازه بیشینه پی‌لود یک بلاک که بیشینه مقدار دارایی‌ها را دربر خواهد گرفت، 58150 بایت خواهد بود. یک دیتابلاک با استفاده از دیتابلاک‌ها و امضاهای (signature) تراکنش‌های تاییدنشده شکل می‌گیرد. سیستم سپس دیتابلاک‌های تراکنشی ترکیب‌شده را هش می‌کند تا پی‌لود بلاک را تولید کند.

تولید بلاک

در شبکه لیسک طبق اجماع  DPoS، در هر 10 ثانیه یک بلاک تولید می‌شود. یک نماینده یک حساب کاربری است که پس از فرایند انتخابات در میان دیگر سهامداران لیسک، این حق را پیدا می‌کند تا بلاک تولید کند. برای تولید بلاک باید 51% از اعضای اصلی از موافقت‌نامه برادهش (broadhash) حمایت کنند که جزییات آن در بخش مربوطه (موافقت‌نامه برادهش) توضیح داده شده است. همین که موافقت‌نامه برادهش به تایید 51% از اعضا رسید، نود (node) مربوطه با استفاده از تکنیک‌های توصیف‌شده در بخش بلاک‌ها، یک بلاک تولید خواهد کرد.

امنیت

لیسک برای اینکه تمام جوانب ایمنی را رعایت کند، از هشینگ (hashing) ارزهای رمزنگاری‌ شده استفاده می‌کند. سیستم لیسک به جای استفاده از ECDSA که در بسیاری از ارزهای رمزنگاری‌ شده مانند بیت‌کوین رواج دارد، از EdDSA استفاده می‌کند، چرا که مکانیزم بسیار سریع‌تری را برای هشینگ و برقراری امنیت عرضه می‌کند.

جفت کلید

یک جفت کلید (key pair) از یک کلید شخصی (private key) و یکی کلید عمومی (public key) تشکیل می‌شود. کلید شخصی اطلاعاتی است که تنها در دست صاحب آن کلید قرار دارد. کلید عمومی از کلید شخصی مشتق می‌شود و برای این استفاده می‌شود تا تایید کند که یک کلید شخصی به یک مالک تعلق دارد، اما هیچ دسترسی‌ به کلید شخصی مالک ایجاد نمی‌کند. برای تولید جفت کلیدهایی که از نظر رمزنگاری ایمن باشند، از سیستم رمزنگاری Elliptic curve استفاده می‌شود.

در روند تولید این جفت‌کلیدها پارامترهای زیر در نظر گرفته می‌‌شود:

نخست اینکه، وقتی یک کاربر یک حسابی ایجاد می‌کند، یک عبارت عبور  BIP39 برای کاربر تولید می‌شود. عبارت عبور با استفاده از تابع هش SHA-256 در یک رشته 256 بیتی هش شده است. این هش متعاقباً در ed25519 به عنوان یک سید (seed) به کار می‌رود تا یک کلید شخصی ks تولید کند و کلید عمومی kp را از آن مشتق می‌سازد.

کاربر با کلید شخصی می‌تواند تراکنش‌ها را در transaction object امضا کند و آن را در شبکه پخش کند. کلید عمومی در قالب بخشی از تراکنش قرار می‌گیرد و نودهایی که تراکنش مربوطه را دریافت می‌کنند، قادر هستند تا اعتبار امضایی که از این kp استفاده می‌کند، تایید نمایند. این امر به طور موثر امنیت را هم برای کاربر و هم برای شبکه بالا می‌برد، چرا که این تنها کاربر است که می‌داند ks چیست و kp می‌تواند تنها اعتبار امضا را تایید کند.

عبارت عبور دوم

لیسک یک لایه امنیتی دیگر را برای کاربران فراهم می‌کند. کاربر می‌تواند برای یک کلاس خاص تراکنش، یک عبارت عبور دوم (second pass phrase) را ثبت کند که با kp متناظر است. به موجب این رابطه تناظر، تمام تراکنش‌های بعدی می‌بایست با استفاده از عبارت عبور دوم امضا شوند تا اینکه اعتبارشان تایید گردد. روند تولید جفت کلید دوم درست مانند تولید جفت کلید اصلی است.

امضای چندگانه

لیسک برای کاربرانی که دغدغه بیشتری برای امنیت دارند، امضای چندگانه (multisignature) را هم به عنوان یک سیستم امنیتی عرضه می‌کند. یک حساب کاربری با امضای چندگانه، حسابی است که چند نفر باید امضا کنند تا تراکنش‌ها تایید و ترتیب اثر داده شود. هر کاربری می‌تواند با صدور یک تراکنش خاص (قسمت تراکنش ثبت امضای چندگانه – Multisignature Registration Transaction را ببینید)، امضای چندگانه را در حساب کاربری خودش فعال کند. با این تراکنش ویژه یک گروه از ksn ها و حداقل تعداد امضاهای مورد نیاز برای تأیید یک تراکنش مشخص می‌شود. آنگاه لازم است تا در بلاکچین، هر تراکنشی که با این حساب کاربری انجام می‌شود، پیش از اینکه ترتیب اثر داده شود، با همان تعداد حداقل حساب کاربری مربوطه امضا شود.

آدرس

آدرس یا ID کیف پول از کلید عمومی مشتق می‌شود. کلید عمومی با استفاده از SHA-256 هش شده و سپس ۸ بایت ابتدایی هش معکوس می‌شوند. ID حساب، نمایش عددی آن  ۸ بایت است و شناسه حساب (account ID) نمایه عددی همان 8 بایت است که یک کاراکتر L ضمیمه آن می‌شود. شکل زیر نشان‌دهنده‌ی یک آدرس و جزئیات حساب مربوط به آن است.

{

“address”: “16009998050678037905L”,

“unconfirmedBalance”: “0”,

“balance”: “0”,

“publicKey”: “73ec4adbd8f99f0d46794aeda3c3d86b245bd9d27be2b282cdd38ad21988556b”,

“unconfirmedSignature”: 0,

“secondSignature”: 0,

“secondPublicKey”: null,

“multisignatures”: [],

“u_multisignatures”: []

}

ارتباط همتاها

ارتباط میان همتاها (peer)، یک نقش حیاتی را درون شبکه‌ی لیسک ایفا می‌کنند. مکانیزم همتاها، معماری مورد نیاز را برای دسترسی به توافق و اجماع (consensus) در شبکه، انتشار بلوک (block propagation) و انتشار تراکنش (transaction propagation) فراهم می‌کند.

هدر (سربرگ)های سیستم

در داخل شبکه‌ی لیسک، هدرهای (header) سیستم جهت شناسایی تمام نودهای بکار رفته و یک مجموعه پایه از اطلاعات را در مورد اجرای سیستم فراهم می‌کنند. حین ارتباطات میان همتاها، این هدرها به تمام پیام‌های ارسال شده بین جفت‌ها، افزوده می‌شوند.

شکل JSON زیر از داده‌ی سیستم، بدین منظور تولید شده و در حین برقراری تمام ارتباطات به شبکه برادکست (broadcast) می‌شود.

{

“os”:”darwin16.3.0″,

“version”:”0.6.0a”,

“port”:7000,

“height”:1574654,

“nethash”:”da3ed6a45429278bac2666961289ca17ad86595d33b31037615d4b8e8f158bba”,

“broadhash”:”c7e0902a7016205d456a427edda2b09f4b875f98ef40a224018a0274347146ac”,

“minVersion”:”>=0.5.0″

}

اجماع برادهش

اجماع برادهش (broadhash consensus) عملکردی حیاتی را در شبکه‌ی لیسک به منظور جلوگیری از فورک‌ها (fork)‌ ایفا می‌کند. در سیستم DPoS، نمایندگان (delegate) بر اساس اسلات‌ها (slot) تعیین شده‌اند و وقتی که سیستم، اسلات آن نماینده را به عنوان حاضر تعیین می‌کند، تلاش خواهد کرد تا یک بلوک را بسازد. توافق‌های برادهش تضمین می‌کنند که اکثریت همتاهای حاضر موافق هستند که تولید این بلاک قابل قبول است.

برادهش به عنوان یک هش تجمیع‌شده متراکم است که از پنج بلاک آخر موجود در پایگاه‌ داده (database) ایجاد شده است. تمام همتا‌ها با بلاک مشابه، ‌یک برادهش را تولید کرده، آن اطلاعات را از طریق هدرهای سیستم که در بخش قبلی توضیح داده شد، منتشر می‌کنند.

انتشار بلاک

انتشار بلاک عملکردی حیاتی را درون شبکه‌ لیسک ایفا می‌کند. بلاک‌ها به صورت غیر متمرکز ایجاد شده و باید به تمام نودهای یافت شده روی شبکه ارسال شوند تا توافق و اجماع ایجاد شود.

صف انتظار برادهش

صف انتظار برادهش (broadhash queue)، نقشی اساسی برای شبکه‌ی لیسک ایفا می‌کند. تراکنش‌ها باید از یک نود به تمام نودهای دیگر حرکت کنند تا در بلاک‌ها گنجانده شوند. صف برادکست با گرفتن حداکثر 25 تراکنش از استخر تراکنش‌ و تجمیع آن‌ها به صورت یک دسته، کار می‌کند. سپس این دسته، با یک فاصله‌ی زمانی که در حال حاضر 5 ثانیه است، در شبکه برادکست می‌شوند. علاوه بر برادکست شدن، به این دسته‌ها یک حد تاخیر (relay limit) داده شده است تا از برادکست شدن بیش از حد داده جلوگیری شود. در حال حاضر، حد تاخیر بر روی 2 تنظیم شده است که بدین معنی است که تمام دسته‌ها یک بار از نود اصلی و دو بار دیگر از نودهای دریافت‌کننده برادکست می‌شوند.

استخر تراکنش

استخر تراکنش (transaction pool) یک راه حل بسیار نوین برای نگهداری از تراکنش‌های تأییدنشده است که به بلاک بعدی سرریز شده‌اند. همانطور که در بخش 6 عنوان شده است، هر بلاک تنها می‌تواند 25 تراکنش را شامل شود و استخر تراکنش بستری را فراهم می‌کند تا چیزی در حدود 5000 تراکنش برای بلاک(های) بعدی در صف انتظار باقی بماند. استخر تراکنش را می‌توان به مثابه یک استخر حافظه دانست که تراکنش‌ها را آماده نگه می‌دارد تا زمانی که امضا شوند و به بلاک راه پیدا کنند.

دومین کاربرد استخر تراکنش فراهم کردن یک مکانیزمی برای انتشار تراکنش‌هاست. وقتی یک نود یک دسته تراکنش‌ را آماده‌سازی می‌کند، 25 تراکنش را از استخر بیرون می‌کشد و به آن‌ها اعتبار می‌بخشد. این تراکنش‌ها سپس در قالب یک آبجکت JSON دسته‌بندی‌شده به نودهای دیگر برادکست می‌شوند. این دسته را می‌توان به صورت یک آرایه از آبجکت‌هایی با انواع مختلف تراکنش دانست که در بخش 5 فهرست شده است.

برای اینکه استخر تراکنش تمیز و مرتب بماند، عمر مشخصی به تمام تراکنش‌ها داده می‌شود. مدت زمان عمر آن‌ها 10800 ثانیه، یا 1080 بلاک تعریف شده است.

در نهایت استخر تراکنش خانه‌ای برای تراکنش‌هایی هست که در انتظار امضا به سر می‌برند. این تراکنش‌ها که در انتظار امضا به سر می‌برند، دقیقا به مانند تراکنش‌های تأییدنشده تلقی می‌شوند. تراکنش‌های چندامضایی نیز همین حکم را دارند. درست مانند تراکنش‌های تأییدنشده، این تراکنش‌ها پس از سپری شدن عمرشان منقضی می‌شوند. البته مدت زمان عمر آن‌ها در هنگام تولیدشان مشخص می‌شود.

تراکنش ها

انواع تراکنش‌های فعال بر روی شبکه

انواع تراکنش‌های در دست ایجاد

Type 0: انتقال دارایی ها به یک حساب ویژه لیسک Type 5: ثبت یک اپلیکیشن بر روی بلاکچین
Type 1: ایجاد secret دوم Type 6: انتقال لیسک به زنجیره های فرعی
Type 2: ثبت یک نماینده Type 7: خارج کرن لیسک از زنجیره های فرعی
Type 3: ثبت رای برای یک نماینده
Type 4: ثبت امضای چندگانه

در لیسک هر تراکنش با یک نوعی مشخص می‌شوند. انواع این تراکنش‌‌ها در جدول نشان داده شده است.

هر تراکنش، صرف نظر از نوع آن، باید پیش از اینکه در شبکه پذیرفته شود، روند امضا شدن را پشت سر بگذارد. نخست، باید یک دیتابلاک که نمایانگر تراکنش است، تولید شود. هر دیتا بلاک شامل یک مجموعه مشخصی از اطلاعات استاندارد می‌شود. با توجه به نوع تراکنش، اطلاعات دیگر دیتا بلاک با یکدیگر تفاوت پیدا می‌کنند.

فیلدهایی که در تمام انواع تراکنش‌ها وجود دارند عبارتند از:

  • یک فیلد 8 بیتی صحیح که نوع تراکنش را مشخص می‌کند
  • فیلد 32 بیتی مهر زمانی آغاز دوره (epoch lifestamp) که زمان درست شدن تراکنش را مشخص می‌کند
  • فیلد 256 بیتی کلید عمومی صادرکننده تراکنش
  • فیلد 64 بیتی صحیح که حاوی مبلغ لیسکی است که باید منتقل شود.

فیلدهای دیگری که به این صورت اضافه می‌شوند به نوع تراکنش بستگی خواهند داشت. همین که یک دیتابلاک تولید می‌شود، با استفاده از الگوریتم SHA-256 هش می‌شود و این هش با استفاده از جفت کلید صادرکننده امضا می‌شود. اگر صادرکننده رمز عبور دوم (Second pass phrase) را فعال کرده باشد، امضای نخست به انتهای دیتابلاک ضمیمه می‌شود، و همین روند تکرار می‌شود، تا امضای دوم نیز تولید گردد. برای حساب‌های چند امضایی هم همین حکم صادق است. شناسه تراکنش (transaction Id) با استفاده از دیتابلاک تولید می‌شود. برای محاسبه شناسه تراکنش، سیستم دیتا بلاک و اطلاعات کامل‌شده امضا را در بر می‌گیرد و این بلاک را با استفاده از SHA-256 هش می‌کند و 8 بایت اول هش را رزرو می‌کند که بعدها به عنوان شناسه تراکنش از آن استفاده می‌شود.

تراکنش انتقال مانده

تراکنش انتقال مانده (balance transfer transaction) (نوع صفر) همان انتقال لیسک از یک حساب به حساب دیگر است. برای اینکه یک تراکنش انتقال مانده را صادر کنیم، باید این فیلدها مشخص شوند:

  • شناسه حساب گیرنده
  • مبلغ لیسک انتقالی
  • رمز حساب

همین که این سه فیلد مشخص شوند، سیستم شروع به ساختن آبجکت تراکنش خواهد کرد. نخست، کلید عمومی فرستنده با استفاده از رمز آن‌ها محاسبه می‌شود. به دنبال آن، درست مانند فرایندی که در بخش امضای تراکنش توضیح داده شد، دیتابلاک درست می‌شود و فیلد اضافی شناسه گیرنده به آبجکت اضافه می‌شود. دیتابلاک در نهایت اندازه‌ای بالغ بر 53 بایت پیدا می‌کند.

این بلاک سپس با استفاده از روشی که در بخش 2.1 شرح داده شد، امضا می‌شود. گام نهایی فرایند تولید تراکنش محاسبه قیمت تراکنش است. قیمت این تراکنش در حال حاضر در سیستم 0.1 لیسک است. پس از طی تمام این مراحل و تأیید تراکنش، تراکنش به شبکه برادکست می‌شود. در عین حال که تراکنش ممکن است در شبکه موجود باشد، ولی باز هم تا زمانی که توسط یک نماینده پردازش نشده باشد، در حالت تأییدنشده باقی می‌ماند. وقتی تراکنش به شبکه برادکست می‌شود، با استفاده از HTTP API به صورت یک آبجکت JSON در می‌آید.

شکل زیر نمایه‌ی یک آبجکت تراکنش است.

شکل زیر نمایه‌ای از یک JSON است.

{

“type”: 0,

“amount”: Amount,

“senderPublicKey”: Public key of the sender,

“timestamp”: Timestamp,

“recipientId”: Id of the recipient,

“signature”: Signature of the data block,

“id”: Id of the transaction,

“fee”: 10000000,

“senderId”: Id of the sender,

}

اندازه نهایی یک تراکنش انتقال مانده بدون رمز عبور دوم 117 بایت است، و همراه با رمز عبور دوم بالغ بر 181 بایت می‌شود.

تراکنش ثبت امضای دوم

یک تراکنش ثبت امضای دوم (second signature registration transaction) (نوع 1) برای ثبت یک رمز عبور دوم در بلاکچین به کار می‌رود. برای صادر کردن این نوع از تراکنش فیلدهای زیر باید مشخص شوند؛ فیلد رمز، حاوی رمز حساب و فیلد رمز دوم که حاوی عبارت رمز دوم است.

همین که این دو فیلد مشخص شدند، سیستم شروع به ساختن تراکنش خواهد کرد. روندی که در بخش 5.1 توضیح داده شد، برای این تراکنش نیز صادق است. کلید عمومی دوم با استفاده از عبارت رمز دوم ساخته می‌شود و سیستم یک دیتابلاک 85 بایتی را می‌سازد. این دیتابلاک سپس با استفاده از ks رمز کاربر امضا می‌شود و امضا به آبجکت ضمیمه می‌شود. به دنبال آن محاسبه قیمت برای این نوع از تراکنش آغاز می‌شود. در حال حاضر کارمزد یک تراکنش امضای دوم در مبلغ 5 لیسک ثابت است.‌

آبجکت نهایی درست به شکل نمودار زیر درمی‌آید.

آبجکت JSON که در شبکه برادکست می‌شود به شکل نمودار زیر در می‌آید.

{

“type”: 1,

“amount”: 0,

“senderPublicKey”: Public key of the sender,

“timestamp”: Timestamp,

“recipientId”: null,

“signature”: Signature of the data block,

“id”: Id of the transaction,

“fee”: 500000000,

“senderId”: Id of the sender,

“asset”: {

“signature”: {

“publicKey”: The public key associated with the second passphrase

}

}

}

اندازه نهایی تراکنش، همراه با امضا بالغ بر 149 بایت می‌شود.

تراکنش ثبت نماینده

یک تراکنش نماینده (delegate registration transaction) (نوع 2) برای ثبت یک حساب به صورت یک نماینده به کار می‌رود. برای صدور یک تراکنش ثبت نماینده، فیلد رمز، حاوی رمز حساب و فیلد نام کاربری حاوی نام کاربری نماینده مورد نیاز هستند.

طول نام کاربری باید حداقل یک کاراکتر و حداکثر 20 کاراکتر باشد. همین که این فیلدها مشخص شدند، در گام بعد سیستم، کلید عمومی حساب را محاسبه و کار ساختن دیتابلاک تراکنش را با حداکثر 73 بایت آغاز می‌کند.

این دیتابلاک سپس با استفاده از رمز حساب امضا می‌شود و امضا به آبجکت تراکنش ضمیمه می‌گردد. سیستم سپس قیمت تراکنش را محاسبه می‌کند. در حال حاضر قیمت یک تراکنش ثبت نماینده ثابت است و 25 لیسک می‌باشد.

آبجکت نهایی به شکل نمودار زیر در می‌آید.

آبجکت JSON که به شبکه برادکست می‌شود نیز فرمت زیر را پیدا می‌کند.

{

“type”: 2,

“amount”: 0,

“senderPublicKey”: Public key of the sender,

“timestamp”: Timestamp,

“recipientId”: null,

“signature”: Signature of the data block,

“id”: Id of the transaction,

“fee”: 10000000000,

“senderId”: Id of the sender,

“asset”: {

“delegate”: {

“username”: The chosen username

“publicKey”: The public key of the delegate (the sender)

}

}

}

در نهایت اندازه تراکنش همراه با امضا حداکثر 137 بایت و همراه با امضای دوم 201 بایت می‌شود.

تراکنش رای

یک تراکنش رأی (vote transaction) (نوع 3)، تراکنشی است که از آن برای رای دادن به نماینده ها استفاده می‌شود. برای اینکه یک تراکنش رأی صادر کنیم، دو فیلد مورد نیاز است:

  • رمز (secret) حاوی رمز حساب
  • فیلد نماینده ها (delegates) شامل آرایه‌ای از رأی‌ها

در ابتدای یک رأی، یک «+» اضافه می‌شود تا سهم‌ها به کلید عمومی نماینده افزوده شود، همچنین اگر حساب کاربری مربوطه بخواهد رأی خود به آن نماینده را پس بگیرد، یک «-» به ابتدای آن افزوده می‌شود. بیشینه تعداد اپلیکیشن‌های رأی 33 است. همین که این فیلدها مشخص شدند، سیستم کلید عمومی حساب را محاسبه و کار ساختن دیتا بلاک تراکنش را با حداکثر 2198 بایت، آغاز می‌کند.

این دیتا بلاک سپس با استفاده از رمز حساب امضا می‌شود، و امضا ضمیمه آبجکت تراکنش می‌شود. سیستم سپس قیمت تراکنش را محاسبه می‌کند. در حال حاضر، قیمت یک تراکنش رأی به مبلغ ثابت 1 لیسک رسیده است.

آبجکت نهایی به صورت نمودار زیر در می‌آید.

آبجکت JSON که در نهایت به شبکه برادکست می‌شود، به فرمت زیر در می‌آید.

{

“type”: 3,

“amount”: 0,

“senderPublicKey”: Public key of the sender,

“timestamp”: Timestamp,

“recipientId”: Id of the sender,

“signature”: Signature of the data block,

“id”: Id of the transaction,

“fee”: 100000000,

“senderId”: Id of the sender,

“asset”: {

“votes”: Array of votes

}

}

اندازه نهایی تراکنش همراه با امضا 2262 بایت می‌شود و با امضای دوم به 2326 بایت افزایش می‌یابد.

تراکنش ثبت امضای چندگانه

یک تراکنش ثبت امضای چندگانه (multisignature registration transaction) (نوع 4) تراکنشی است که برای افزودن امضای چندگانه به یک حساب کاربری استفاده می‌شود. برای کسب اطلاعات بیشتر در مورد امضای چندگانه به بخش 3.3 مراجعه کنید. فیلدهای زیر برای صدور یک تراکنش ثبت امضای چندگانه لازم هستند:

  • فیلد رمز (secret) حاوی رمز حسابی که امضای چندگانه بر آن اعمال خواهد شد.
  • فیلد گروه کلیدها (key group) که آرایه کلیدهایی را مشخص می‌کند که باید به حساب افزوده شوند یا از آن حذف شوند.
  • فیلد مین (min) که حداقل مقدار امضاهایی را مشخص می‌کند که برای تایید یک تراکنش لازم است (مقدار آن حداقل می‌تواند 2 باشد).
  • فیلد طول عمر (lifetime) زمان انتظار برای کسب امضاهای کافی را پیش از حذف شدن تراکنش مشخص می‌کند.

به ابتدای هر کلید عمومی در گروه کلیدها یک «+» افزوده می‌شود و تنها پس از آن است که کلید عمومی به حساب چندامضایی افزوده می‌شود. تعداد امضایی که برای تایید یک تراکنش لازم است باید بیشتر از 2 و کمتر از 16 باشد. تعداد کلیدها در گروه کلیدها باید بیشتر از 2 باشد. طول عمر به ساعت مشخص می‌شود و باید مقداری بیشتر از 1 ساعت و کمتر از 24 ساعت داشته باشد. پس از مشخص شدن این فیلدها، سیستم کلید عمومی حساب را محاسبه و شروع به ساختن دیتابلاک تراکنش می‌کند. اندازه دیتابلاک به تعداد کلیدهایی بستگی دارد که به تراکنش ثبت امضای چندگانه افزوده شده‌اند. به خاطر افزوده شدن مدیفایر (modifier) هر کلید بالغ بر 65 بایت می‌شود.

این دیتابلاک با استفاده از رمز کاربر امضا می‌شود، و امضا ضمیمه آبجکت تراکنش می‌گردد. سپس سیستم قیمت تراکنش را حساب می‌کند. در حال حاضر قیمت تراکنش ثبت امضای چندگانه بالغ بر 5 لیسک به ازای هر کلید در گروه کلیدها می‌شود. بدیهی است که کلید حسابی که تراکنش را صادر می‌کند، خود به خود به امضای چندگانه افزوده می‌شود.

نمودار زیر آبجکت نهایی را نشان می‌دهد:

آبجکت JSON که در نهایت به شبکه برادکست می‌شود، فرمتی شبیه به فرمت زیر پیدا می‌کند.

{

“type”: 4,

“amount”: 0,

“senderPublicKey”: Public key of the sender,

“timestamp”: Timestamp,

“recipientId”: null,

“signature”: Signature of the data block,

“id”: Id of the transaction,

“fee”: Transaction fee,

“senderId”: Id of the sender,

“asset”: {

“multisignature”: {

“min”: The minimum of signature required,

“lifetime”: The lifetime of the transaction,

“keysgroup”: Array of keys to add in the multisignature

}

}

}

اندازه نهایی یک تراکنش ثبت امضای چندگانه با دو کلید 249 بایت است و اگر عبارت رمز دوم (second pass phrase) فعال شده باشد، اندازه‌اش به 313 بایت افزایش پیدا می‌کند.

اجماع

لیسک از اثبات سهام محول شده (Delegated Proof of Stake -DPoS) برای سیستم توافق و اجماع (consensus) خود استفاده می‌کند. نماینده ها تمام بلاک‌های سیستم را می‌سازند. آن‌ها توسط یک سیستم انتخاباتی با رقابت‌پذیری بالا توسط سهامداران انتخاب می‌شوند. سهامداران N تعداد از نماینده ها (در حال حاضر N=101) را برای تولید بلاک انتخاب می‌کنند. هر سهامدار می‌تواند به 101 نماینده رأی دهد و ارزش هر رأی به مبلغ لیسکی بستگی دارد که آن سهامدار در مالکیت خود دارد. یک سهامدار می‌تواند با استفاده از یک تراکنش رأی به یک نماینده خاص رأی دهد.

یکی از جوانب لازم هر سیستم بلاکچینی، اجماع است. در سیستمی که از نودهای بیشماری تشکیل شده است و تمام نودها باید در مورد تمامیت دیتاها توافق داشته باشند، اجماع نقش مهمی دارد. تمام نودهای مشارکت‌کننده باید در مورد اینکه کدام دیتای تراکنشی مشروع است، توافق داشته باشند تا بلاکچین مسیر روبه رشدی طی کند.

نماینده ها

یک نماینده (delegate)، نوعی حساب کاربری است که با استفاده از تراکنش ثبت نماینده (بخش قبلی)، ثبت شده است. این حساب‌ها هدف ویژه‌ای در لیسک دارند، چرا که اجازه دارند تا برای سیستم، بلاک تولید کنند. آن‌ها در صورتی اجازه این کار را پیدا خواهند کرد که کاربران دیگر سیستم به اندازه کافی به او سهم اختصاص دهند. هر حساب کاربری می‌تواند به یک نماینده تبدیل شود، اما تنها آن حساب‌هایی اجازه دارند بلاک تولید کنند که به مقدار کافی سهم داشته باشند.

راند نماینده

یک راند در این سیستم دقیقا N بلاک طول دارد (N معادل کل تعداد نماینده های فورجینگ است). در طول یک راند، هر نماینده دقیقا یک بلاک تولید خواهد کرد. اگر یک نماینده انتخاب‌شده نتواند در یک راند دست به تولید بزند، نماینده دیگری بلاک او را به جایش خواهد ساخت. در آغاز هر راند، یک اسلات (slot) به هر نماینده اختصاص داده می‌شود که جایگاه آن‌ها را در فرایند تولید بلاک مشخص می‌کند. وقتی که یک نود با یک نماینده فعال، یک بلاک تولید می‌کند، نود مربوط به آن نماینده بیش از 25 تراکنش در بلاک را شامل می‌شود، بلاک را امضا می‌کند و آن را به شبکه برادکست می‌کند. همین که بلاک به شبکه دست پیدا کرد، نماینده بعدی با اسلاتی که به آن اختصاص داده شده است، دست به تولید خواهد زد.

پاداش‌های شبکه

برای اینکه نماینده ها مشوق خوبی برای فراهم کردن امنیت برای شبکه داشته باشند، تراکنش‌های پرداخت‌شده بر روی شبکه به طور مساوی در میان تمام نماینده های فعال تقسیم می‌شود. علاوه بر این، پاداش تولید بلاک (یا به اصطلاح پاداش فرجینگ -forging) در میان تک تک تولیدکنندگان بلاک توزیع می‌شود.

پاداش‌های بلاک

درست مانند بیت‌کوین و تقریبا تمام سیستم‎های بلاکچینی دیگر، لیسک نیز به تولیدکنندگان بلاک مبلغ ثابتی به ازای هر بلاکی که به طور موفقیت‌آمیز تولید می‌کنند و توسط سیستم پذیرفته می‌شود، پاداش می‌دهد. در سیستم لیسک، تمام نماینده های فعالی که مشارکت موفقیت‌آمیزی برای ایمن نگه داشتن شبکه داشته‌اند، پاداش می‌گیرند.

جدول زمانی برای پاداش‌های بلاک در شکل زیر نمایش داده شده است:

Block Reward Reduction

milestones: [
500000000, // Initial Reward begins at block 1,451,520
400000000, // Milestone 1 begins at block 4,451,520
300000000, // Milestone 2 begins at block 7,451,520
200000000, // Milestone 3 begins at block 10,451,520
100000000 // Milestone 4 begins at block 13,451,520
],

پاداش بلاک به طور خطی با افزایش عمر شبکه، کاهش پیدا می‌کند. این امر نماینده ها را تشویق می‌کند تا به طور فعالی در شبکه مشارکت داشته باشند. پس از هر 3000000 بلاک، پاداش به اندازه یک پله نسبت به میزان قبلی خود کاهش پیدا می‌کند.

قیمت‌های راند

مشوق دومی که از طرف سیستم ارائه می‌شود، کارمزد راند (round fee) است. یک راند (round)، که در بخش 6.1 تعریف شده است، پس از تولید چند بلاک مشخص‌شده به وجود می‌آید. در پایان این فرایند، تمام قیمت‌ها تجمیع می‌شوند و متعاقبا در میان تمام طرف‌های فعال در این راند، تقسیم می‌شود. این قیمت‌ها می‌توانند پاداش قابل توجهی برای آن دست‌اندارکارانی باشند که در خارج از حوزه تولید بلاک فعالیت می‌کنند، به شرطی که فعالیت‌های تراکنشی قابل توجهی در سیستم موجود باشد.

برای یک نماینده این امکان وجود دارد که سهم‌های متعددی از این قیمت‌ها به دست بیاورد. این امر زمانی اتفاق می‌افتد که نماینده بلاک‌های متعددی در یک راند بسازد. در اغلب مواقع این اتفاق نمی‌افتد، گرچه ممکن است یک نود نماینده (delegate node) دیگر، در طول مراحل تخصیص اسلات (assigned slot) به نماینده ها آفلاین باشد و متعاقبا این امکان وجود ندارد تا یک بلاک را برای یک اسلات تخصیص‌داده‌شده بسازد. به عبارت دیگر دلگیت اسلات خود را از دست خواهد داد و بنابراین نماینده دیگری در عوض بلاک‌های متعدد را در طول این راند تولید خواهد کرد.

تراکنش‌های منسوخ‌شده

ضمیمه حاوی اسناد قدیمی است و برای آن دسته از تراکنش‌هایی آماده شده است که دیگر پشتیبانی نمی‌شوند اما هنوز درون سیستم فعال می‌باشند. این تراکنش‌ها به قسمت پشتیبانی از اپلیکیشن‌های قدیمی (legacy applications support) ارجاع داده می‌شوند و نباید مورد استفاده قرار بگیرند. آن‌ها برای تکمیل مدارک در اینجا بایگانی می‌شوند.

تراکنش ثبت اپلیکیشن‌

یک تراکنش ثبت اپلیکیشن (Application registration transaction) (نوع 5) تراکنشی است که برای ثبت یک اپلیکیشن مورد استفاده در یک زنجیره جانبی (sidechain) به کار می‌رود. برای اطلاعات بیشتر در مورد اپلیکیشن‌های بلاکچینی به بخش 7 مراجعه کنید. فیلدهای زیر برای صدور یک تراکنش ثبت اپلیکیشن لازم هستند:

  • فیلد رده (Category)، برای رده اپلیکیشن
  • فیلد نام (Name)، برای نام اپلیکیشن
  • فیلد نوع (Type)، برای نوع اپلیکیشن
  • فیلد لینک (Link) برای لینکی که از طریق آن اپلیکیشن دانلود می‌شود.

فیلدهای زیر نیز وجود دارند که می‌توانند در این نوع تراکنش مشخص شوند:

  • فیلد شرح (desciption)، برای شرح اپلیکیشن
  • فیلد آیکون (Icon) برای آیکون اپلیکیشن
  • در نهایت فیلد تگ‌ها (Tags) برای تگ‌های اپلیکیشن اختیاری هستند.

با مشخص شدن این فیلدها، سیستم کلید عمومی حساب کاربری را محاسبه خواهد کرد و کار ساختن دیتابلاک تراکنش را مانند شکل زیر آغاز خواهد کرد.

این دیتا بلاک سپس با استفاده از رمز حساب کاربری امضا می‌شود و امضا به این دیتا بلاک ضمیمه می‌شود. سیستم قیمت تراکنش را محاسبه می‌کند. در حال حاضر، قیمت یک تراکنش ثبت اپلیکیشن 500 لیسک است. آنچه که در ادامه می‌آید، نمایه‌ای از آبجکت JSON نهایی است که به شبکه برادکست خواهد شد.

{

“type”: 5,

“amount”: 0,

“senderPublicKey”: Public key of the sender,

“timestamp”: Timestamp,

“recipientId”: null,

“signature”: Signature of the data block,

“id”: Id of the transaction,

“fee”: 50000000000,

“senderId”: Id of the sender,

“asset”: {

“dapp”: {

“category”: The category of the application,

“name”: The name of the application,

“type”: The type of the application,

“link”: The link of the application,

“description”: The description of the application,

“icon”: The icon of the application,

“tags”: Tags of the application

}

}

}

اندازه نهایی تراکنش ممکن است، با توجه به اندازه محتوا تفاوت پیدا کند. در حالت کلی آبجکت نهایی اندازه‌ای بین 150 تا 200 بایت پیدا خواهد کرد. شناسه اپلیکیشن (application Id) دقیقا با شناسه تراکنش (Transaction Id) یکسان است.

تراکنش انتقالی درونسو

یک تراکنش انتقالی درونسو (In Transfer transaction )، تراکنشی است که برای انتقال وجوه از زنجیره اصلی به زنجیره طرف اپلیکیشن به کار می‌رود. برای صدور یک تراکنش درونسو سه فیلد باید مشخص شود.

  • نخست فیلد رمز (Secret) یا همان رمز حساب کاربری
  • دوم فیلد مبلغ (Amount) یا همان مبلغ لیسکی که باید منتقل شود
  • سوم شناسه دَپ (dappId) که شناسه اپلیکیشن را مشخص می‌کند.

این بلاک دیتا با استفاده از رمز حساب کاربری امضا می‌شود و سپس امضا ضمیمه بلاک می‌شود. سیستم سپس قیمت تراکنش را محاسبه می‌کند. در حال حاضر، قیمت یک تراکنش درونسو 0.1 لیسک است.

شکل زیر نمایه آبجکت JSON نهایی است که در شبکه برادکست خواهد شد.

{

“type”: 6,

“amount”: Amount to transfer,

“senderPublicKey”: Public key of the sender,

“timestamp”: Timestamp,

“recipientId”: null,

“signature”: Signature of the data block,

“id”: Id of the transaction,

“fee”: 10000000,

“senderId”: Id of the sender,

“asset”: {

“inTransfer”: {

“dappId”: Id of the application

}

}

}

اندازه نهایی تراکنش، همراه با امضا 136 بایت خواهد بود و همراه با امضای دوم به 200 باید خواهد رسید.

تراکنش انتقالی برونسو

یک تراکنش انتقالی برونسو (Out Transfer Transaction)، تراکنشی است که برای انتقال وجوه از سمت زنجیره اپلیکیشن به سمت زنجیره اصلی به کار می‌رود. یک تراکنش انتقالی برونسو تنها از سوی صاحب یک اپلیکیشن صادر می‌شود. فیلدهای مورد نیاز برای صدور یک تراکنش انتقالی برونسو عبارتند از:

  • نخست فیلد رمز (Secret) که همان رمز حساب صاحب اپلیکیشن است
  • دوم فیلد شناسه گیرنده (recipientId)، که شناسه کاربری را مشخص می‌کند که مبلغ برداشتی را می‌فرستد.
  • سوم فیلد مبلغ (amount)، که مبلغ لیسکی که باید انتقال یابد را مشخص می‌کند.
  • چهارم فیلد شناسه تراکنش (Transaction Id)، که همان شناسه تراکنش برداشت در زنجیره سمت اپلیکیشن است.
  • در نهایت شناسه دپ (dappId) که همان شناسه اپلیکیشن است.

با مشخص شدن این فیلدها، سیستم کلید عمومی حساب کاربری را با محاسبات تولید می‌کند و کار ساختن بلاک دیتای تراکنش با حداکثر 93 بایت را آغاز می‌کند.

این دیتا بلاک با استفاده از رمز حساب کاربری امضا می‌شود و این امضا در پایان به پیوست آن افزوده می‌شود. ما سپس باید قیمت تراکنش را محاسبه کنیم. در حال حاضر، قیمت یک تراکنش انتقالی برونسو بالغ بر 0.1 لیسک است.

شکل زیر نمایه‌ای از آبجکت JSON نهایی را نشان می‌دهد که در شبکه برادکست خواهد شد.

{

“type”: 7,

“amount”: Amount to transfer,

“senderPublicKey”: Public key of the sender,

“timestamp”: Timestamp,

“recipientId”: Id of the recipient,

“signature”: Signature of the data block,

“id”: Id of the transaction,

“fee”: 10000000,

“senderId”: Id of the sender,

“asset”: {

“outTransfer”: {

“dappId”: Id of the application,

“transactionId”: Id of the withdrawal transaction

}

}

}

اندازه نهایی تراکنش، همراه با امضای 157 بایت است و اگر امضای دومی هم در کار باشد به 221 بایت افزایش پیدا خواهد کرد.

شاید از این مطالب هم خوشتان بیاید.

ارسال پاسخ

آدرس ایمیل شما منتشر نخواهد شد.