Mastering Blockchain

خلاصه‌ی کتاب

معرفی کتاب

Mastering Blockchain: Distributed Ledger Technology, Decentralization, and Smart Contracts Explained کتابی است از ایمران بشیر (Imran Bashir) که انتشارات Packt ویرایش دوم آن را در مارس ۲۰۱۸ منتشر کرد. این کتاب مرجعی گسترده و فنی درباره‌ی خود فناوری بلاک‌چین است، نه فقط یک ارز: از مفاهیم دفتر کل توزیع‌شده، تمرکززدایی و اجماع شروع می‌کند، رمزنگاری لازم را توضیح می‌دهد، سراغ بیت‌کوین و ارزهای جایگزین می‌رود و بعد به قرارداد هوشمند، اتریوم، Solidity، Web3 و Hyperledger می‌رسد. فصل‌های پایانی هم مقیاس‌پذیری، کاربردهای غیرمالی و چشم‌انداز آینده را بررسی می‌کنند.

کتاب برای کسی نوشته شده که می‌خواهد بلاک‌چین را «در عمق» بفهمد: توسعه‌دهنده، دانشجو یا مدرس. آشنایی پایه با علوم کامپیوتر و کمی برنامه‌نویسی کمک می‌کند، ولی نویسنده مطالب زمینه‌ای را در جای خود می‌آورد و بدون آن‌ها هم می‌شود کتاب را خواند. ۱۹ فصل دارد و حجم آن بیش از ششصد صفحه است. برای همین این صفحه هر فصل را جدا خلاصه کرده است.

چاپ‌ها و دسترسی

• ویرایش دوم (۲۰۱۸): خلاصه‌ی این صفحه بر پایه‌ی همین ویرایش نوشته شده است و دکمه‌ی صفحه به صفحه‌ی همین ویرایش در Packt می‌رود.
• ویرایش سوم: نسخه‌ی تازه‌تری از کتاب هم منتشر شده است. اگر قصد خرید دارید، پیش از خرید ویرایش را بررسی کنید.
• مجوز: برخلاف Mastering Bitcoin، این کتاب با مجوز آزاد منتشر نشده و متن کامل آن را باید از ناشر یا کتاب‌فروشی‌ها تهیه کرد.

پیش از خواندن: این صفحه ترجمه‌ی کتاب نیست؛ خلاصه‌ای مستقل و مفصل به زبان فارسی است و جای متن اصلی را نمی‌گیرد. چون بر پایه‌ی ویرایش دوم (۲۰۱۸) است، بعضی بخش‌ها با وضعیت امروز فرق دارند: اتریوم در آن زمان هنوز با اثبات کار (PoW) کار می‌کرد، نسخه‌های Solidity و ابزارهای توسعه‌ی معرفی‌شده قدیمی‌اند و فصل «چشم‌انداز کنونی» وضعیت همان سال را توصیف می‌کند. برای کد و جزئیات دقیق، سراغ مستندات رسمی هر ابزار بروید.

این خلاصه به چه درس‌هایی کمک می‌کند؟

فصل‌های ۱ و ۲ (مبانی بلاک‌چین و تمرکززدایی) به مباحث دوره‌ی «معرفی بلاک‌چین و رمزارز» (G1) نزدیک‌اند و فصل‌های ۵ تا ۷ به دوره‌ی «بیت‌کوین» (G2). فصل‌های ۹ تا ۱۴ (قرارداد هوشمند، اتریوم، Solidity و Web3) پیش‌زمینه‌ی خوبی برای دوره‌ی «مبانی سالیدیتی» (B1) هستند. فصل‌های ۱۵ تا ۱۹ دید کلی‌تری از پلتفرم‌های دیگر و محدودیت‌های بلاک‌چین می‌دهند.

فهرست خلاصه‌ی فصل‌ها

1. پیشگفتار
2. فصل ۱ — مبانی بلاک‌چین (Blockchain 101)
3. فصل ۲ — تمرکززدایی (Decentralization)
4. فصل ۳ — رمزنگاری متقارن (Symmetric Cryptography)
5. فصل ۴ — رمزنگاری کلید عمومی (Public Key Cryptography)
6. فصل ۵ — معرفی بیت‌کوین (Introducing Bitcoin)
7. فصل ۶ — شبکه و پرداخت‌های بیت‌کوین (Bitcoin Network and Payments)
8. فصل ۷ — کلاینت‌ها و APIهای بیت‌کوین (Bitcoin Clients and APIs)
9. فصل ۸ — ارزهای جایگزین (Alternative Coins)
10. فصل ۹ — قراردادهای هوشمند (Smart Contracts)
11. فصل ۱۰ — مقدمه‌ای بر اتریوم (Ethereum 101)
12. فصل ۱۱ — ادامهٔ اتریوم (Further Ethereum)
13. فصل ۱۲ — محیط توسعهٔ اتریوم (Ethereum Development Environment)
14. فصل ۱۳ — ابزارها و فریم‌ورک‌های توسعه (Development Tools and Frameworks)
15. فصل ۱۴ — معرفی Web3 (Introducing Web3)
16. فصل ۱۵ — هایپرلجر (Hyperledger)
17. فصل ۱۶ — بلاک‌چین‌های جایگزین (Alternative Blockchains)
18. فصل ۱۷ — بلاک‌چین فراتر از ارزهای دیجیتال (Blockchain – Outside of Currencies)
19. فصل ۱۸ — مقیاس‌پذیری و چالش‌های دیگر (Scalability and Other Challenges)
20. فصل ۱۹ — چشم‌انداز کنونی و گام بعدی (Current Landscape and What’s Next)

پیشگفتار

هدف کتاب و دلیل ویرایش دوم

• هدف اصلی کتاب این است که جنبه‌های نظری و عملی فناوری بلاک‌چین (Blockchain) را یک‌جا ارائه دهد؛ به‌گونه‌ای که خواننده در پایان بتواند به یک متخصص فنی این حوزه تبدیل شود.
• از زمان انتشار ویرایش اول، بلاک‌چین پیشرفت زیادی کرده است و همین نیاز به به‌روزرسانی کتاب را پدید آورده است.
• نویسنده توضیح می‌دهد که مزایای بسیاری که برای این فناوری پیش‌بینی می‌شود، علاقهٔ شدیدی در دانشگاه و صنعت برانگیخته است. در نتیجه کنسرسیوم‌ها، گروه‌های کاری، پروژه‌ها و نهادهای حرفه‌ای متعددی برای توسعه و پیشبرد آن شکل گرفته‌اند.
• ویرایش دوم بر سه محور تمرکز دارد: تمرکززدایی (Decentralization)، قرارداد هوشمند (Smart Contract) و پلتفرم‌های مختلف مانند Ethereum، Bitcoin و Hyperledger Fabric.
• نتیجهٔ مطلوب: درک عمیق از سازوکار درونی بلاک‌چین و توانایی ساخت برنامه‌های مبتنی بر آن.

کتاب برای چه کسانی است

• هر کسی که می‌خواهد بلاک‌چین را در عمق بفهمد.
• توسعه‌دهندگانی که برای بلاک‌چین برنامه می‌نویسند و به یک مرجع نیاز دارند.
• مدرسان و دانشجویان؛ کتاب می‌تواند کتاب درسی دوره‌های مرتبط با بلاک‌چین و ارزهای رمزنگاری‌شده باشد.
• داوطلبان آزمون‌ها و گواهینامه‌های حوزهٔ رمزارز و بلاک‌چین، به‌عنوان منبع مطالعه.

پیش‌نیازها

• ایدهٔ ایده‌آل: آشنایی پایه با علوم کامپیوتر و کمی تجربهٔ برنامه‌نویسی.
• اگر چنین پیش‌زمینه‌ای وجود نداشته باشد، باز هم خواندن کتاب ممکن است، چون مطالب زمینه‌ای لازم در جای خود ارائه می‌شود.
• موضوعات پوشش‌داده‌شده: رمزنگاری، ارزهای رمزنگاری‌شده، Bitcoin، Ethereum و پلتفرم‌ها و ابزارهای دیگر توسعهٔ بلاک‌چین.

ساختار کتاب: فصل به فصل (۱۹ فصل)

نکات تکمیلی دربارهٔ مسیر کتاب:

• فصل‌های ۱ تا ۴ پایهٔ نظری هستند (توزیع‌شدگی، تمرکززدایی، رمزنگاری).
• فصل‌های ۵ تا ۸ حول Bitcoin و ارزهای جایگزین می‌چرخند.
• فصل‌های ۹ تا ۱۴ به قراردادهای هوشمند و توسعه روی Ethereum اختصاص دارند.
• فصل‌های ۱۵ و ۱۶ پلتفرم‌های دیگر (Hyperledger و بلاک‌چین‌های جایگزین) را بررسی می‌کنند.
• فصل‌های ۱۷ تا ۱۹ کاربردها، چالش‌ها و آینده را پوشش می‌دهند.

محیط و ابزارهای مورد استفاده در مثال‌ها

دریافت کد و تصاویر

• کدهای نمونه از حساب کاربری در سایت Packt (بخش Code Downloads & Errata) قابل دانلود است و در GitHub نیز تحت مخزن Mastering-Blockchain-Second-Edition (متعلق به PacktPublishing) نگهداری و به‌روز می‌شود.
• فایل فشرده را باید با ابزارهایی مثل WinRAR/7-Zip (ویندوز)، Zipeg/iZip/UnRarX (مک) یا 7-Zip/PeaZip (لینوکس) باز کرد.
• یک فایل PDF حاوی تصاویر رنگی نمودارها و اسکرین‌شات‌ها نیز جداگانه عرضه شده است.

قراردادهای نوشتاری کتاب

• متن با قالب کد (CodeInText) برای کلمات کد، نام فایل و پوشه، مسیرها، URLهای فرضی و ورودی کاربر استفاده می‌شود.
• بلوک‌های کد برای نمایش برنامه‌ها (مثلاً یک قرارداد Solidity با struct به نام Trade)؛ بخش‌هایی که باید توجه را جلب کنند پررنگ (bold) می‌شوند.
• ورودی و خروجی خط فرمان با علامت $ نمایش داده می‌شود (مثلاً نصب solc با apt-get).
• واژه‌های جدید و اصطلاحات مهم، و نیز عناصر رابط کاربری (منو و دکمه‌ها)، به‌صورت پررنگ می‌آیند.
• هشدارها و نکته‌های مهم و نیز «ترفندها» با نمادهای جداگانه مشخص شده‌اند.

ارتباط با ناشر

• بازخورد عمومی و پرسش‌ها از طریق ایمیل ناشر و ذکر نام کتاب در موضوع.
• گزارش اشتباهات (Errata) و گزارش نسخه‌های غیرقانونی از طریق سایت و ایمیل‌های مشخص Packt.
• دعوت از متخصصان برای نویسندگی و همچنین درخواست از خوانندگان برای ثبت نقد و بررسی.

جمع‌بندی

پیشگفتار نقشهٔ راه کتاب را روشن می‌کند: کتابی جامع و پیش‌رونده، از مبانی توزیع‌شدگی و رمزنگاری شروع می‌شود، به Bitcoin و Ethereum و Hyperledger می‌رسد، با ابزارهای عملی توسعه ادامه می‌یابد و با کاربردها، چالش‌ها و چشم‌انداز آینده پایان می‌گیرد. مخاطب هدف طیف وسیعی از علاقه‌مندان، توسعه‌دهندگان و دانشجویان است و تنها پیش‌نیاز توصیه‌شده، آشنایی مقدماتی با علوم کامپیوتر و برنامه‌نویسی است. مثال‌ها عمدتاً روی Ubuntu/macOS با OpenSSL، Remix، Truffle، Node.js و Raspberry Pi اجرا شده‌اند.

فصل ۱ — مبانی بلاک‌چین (Blockchain 101)

مقدمه

فصل اول درآمدی بر بلاک‌چین (Blockchain) است: بنیان‌های فنی، نظریهٔ پشت آن و فنونی که کنار هم قرار گرفته‌اند تا چیزی که امروز بلاک‌چین می‌نامیم شکل بگیرد. نویسنده ادعا می‌کند این فناوری وعدهٔ دگرگون‌کردن الگوهای موجود در تقریباً همهٔ صنایع (فناوری اطلاعات، مالی، دولت، رسانه، پزشکی، حقوق) را می‌دهد.

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

1. مبانی نظری سیستم‌های توزیع‌شده؛
2. پیشینیان Bitcoin (پول الکترونیکی) که بلاک‌چین از طریق آن به دنیا معرفی شد؛
3. خود بلاک‌چین: تعریف، اجزا، انواع، مزایا و محدودیت‌ها، ویژگی‌ها و سازوکارهای اجماع.

نویسنده می‌گوید مطالب با سرعت مرور می‌شوند و در فصل‌های بعد با عمق بیشتری بازگشت خواهد شد.

رشد فناوری بلاک‌چین

• با اختراع Bitcoin در ۲۰۰۸ مفهومی جدید وارد جهان شد که احتمال دارد کل جامعه را دگرگون کند (مالی، دولت، رسانه، حقوق، هنر). برخی آن را «انقلاب» و برخی «تکامل تدریجی» می‌دانند که ثمرهٔ عملی‌اش سال‌ها بعد می‌رسد؛ نویسنده معتقد است انقلاب عملاً آغاز شده است.
• سازمان‌های برجستهٔ جهان در حال نوشتن اثبات مفهوم (Proof of Concept) هستند؛ برخی هنوز در مرحلهٔ اکتشاف‌اند.
• خط زمان پیشنهادی نویسنده از نمودار «پذیرش و بلوغ»:

• نویسنده این روند را شبیه رونق دات‌کام اینترنت در اواخر دهه ۱۹۹۰ می‌داند و تأکید می‌کند زمان‌بندی‌ها قطعی نیستند.
• مثال: بورس اوراق بهادار استرالیا (ASX) قرار بود نخستین سازمانی باشد که سامانهٔ قدیمی تسویه و پایاپای (clearing and settlement) خود را با بلاک‌چین جایگزین کند.
• شواهد علاقهٔ فزاینده: اتحادیهٔ اروپا اعلام کرد بودجهٔ پژوهش بلاک‌چین را تا ۲۰۲۰ به حدود ۳۴۰ میلیون یورو (چهار برابر) می‌رساند؛ گزارشی هم پیش‌بینی می‌کرد هزینهٔ جهانی روی پژوهش بلاک‌چین تا ۲۰۲۱ به ۹٫۲ میلیارد دلار برسد. جست‌وجوی «blockchain» در Google از ابتدای ۲۰۱۷ جهش چشمگیری داشت.
• کنسرسیوم‌ها: Enterprise Ethereum Alliance (EEA)، Hyperledger و R3، به‌علاوهٔ استارتاپ‌های فراوان.
• مزایای مورد انتظار: اعتماد غیرمتمرکز، صرفه‌جویی هزینه، شفافیت و کارایی. چالش‌های پژوهشی فعال: مقیاس‌پذیری (scalability) و حریم خصوصی (privacy). بحث کامل‌تر محدودیت‌ها در فصل ۱۸ آمده است.

سیستم‌های توزیع‌شده (Distributed Systems)

• بلاک‌چین در هستهٔ خود یک سیستم توزیع‌شده است؛ یک دفتر کل توزیع‌شده (distributed ledger) که می‌تواند متمرکز یا غیرمتمرکز باشد، اما در اصل برای کاربرد غیرمتمرکز طراحی شده است. نویسنده آن را سیستمی «غیرمتمرکز-توزیع‌شده» می‌نامد که ویژگی هر دو الگو را دارد.
• سیستم توزیع‌شده: الگویی که در آن دو یا چند گره (node) به‌صورت هماهنگ برای رسیدن به یک نتیجهٔ مشترک کار می‌کنند، طوری که کاربر نهایی آن را یک پلتفرم منطقی واحد می‌بیند (مثال: موتور جست‌وجوی Google).
• گره بازیگر منفرد سیستم است: حافظه و پردازنده دارد، پیام ارسال و دریافت می‌کند، و می‌تواند صادق، معیوب یا بدخواه باشد. گرهٔ دارای رفتار نامعقول را گرهٔ بیزانسی (Byzantine node) می‌نامند.

مسئلهٔ ژنرال‌های بیزانسی (Byzantine Generals Problem)

• در ۱۹۸۲ لمپورت و همکاران یک آزمایش فکری مطرح کردند: چند ژنرال که هر یک بخشی از ارتش بیزانس را فرماندهی می‌کنند باید دربارهٔ حمله یا عقب‌نشینی از یک شهر توافق کنند و تنها راه ارتباط، پیام‌رسان است. برای پیروزی باید همزمان حمله کنند، اما ممکن است برخی ژنرال‌ها خائن باشند و پیام گمراه‌کننده بفرستند.
• قیاس: ژنرال‌ها = گره‌ها، خائنان = گره‌های بیزانسی (بدخواه)، پیام‌رسان = کانال ارتباطی.
• راه‌حل: در ۱۹۹۹ کاسترو و لیسکوف الگوریتم PBFT (Practical Byzantine Fault Tolerance) را ارائه کردند که در آن اجماع پس از دریافت تعداد معینی پیام با محتوای امضاشدهٔ یکسان حاصل می‌شود.
• هر رفتار غیرمنتظره از یک گره، چه عمدی چه غیرعمدی، «بیزانسی» محسوب می‌شود.

چالش‌های طراحی

• مثال مقیاس کوچک در کتاب: شبکه‌ای با شش گره که یکی (N4) بیزانسی است و می‌تواند ناسازگاری داده بسازد، و پیوندی (L2) که قطع یا کند است و می‌تواند باعث افراز شبکه (partition) شود.
• چالش اصلی: هماهنگی میان گره‌ها و تحمل خطا (fault tolerance)؛ سیستم باید با وجود گره‌های معیوب یا پیوندهای قطع‌شده به کار ادامه دهد.
• سختی طراحی چنان است که قضیهٔ CAP ثابت می‌کند هیچ سیستم توزیع‌شده‌ای نمی‌تواند همزمان سه ویژگی مطلوب (سازگاری، دسترس‌پذیری، تحمل افراز) را داشته باشد (شرح بعداً در همین فصل).

تاریخچهٔ بلاک‌چین و Bitcoin

بلاک‌چین با اختراع Bitcoin در ۲۰۰۸ معرفی شد و پیاده‌سازی عملی‌اش در ۲۰۰۹ رخ داد. بدون ذکر Bitcoin، تاریخچهٔ بلاک‌چین ناقص است.

پول الکترونیکی (Electronic Cash)

• مفهوم پول دیجیتال تازه نیست؛ از دهه ۱۹۸۰ پروتکل‌های e-cash مبتنی بر مدل دیوید چام (David Chaum) وجود داشت.
• دو مسئلهٔ بنیادین هر سیستم e-cash:
  • پاسخ‌گویی (accountability): پول فقط یک بار و فقط توسط مالک مشروع خرج شود؛ یعنی جلوگیری از خرج مضاعف (double-spend). چون کپی داده دیجیتال آسان است، این موضوع جدی است.
  • ناشناسی (anonymity): مانند پول نقد فیزیکی، ردیابی هزینه به فرد پرداخت‌کننده تقریباً ناممکن باشد.
• چام در دهه ۱۹۸۰ هر دو مسئله را با دو عملیات رمزنگاری حل کرد: امضای کور (blind signature) که امکان امضای سند بدون دیدن آن را می‌دهد، و اشتراک راز (secret sharing) که تشخیص خرج مضاعف (استفاده دوباره از یک توکن e-cash) را ممکن می‌کند. (جزئیات در فصل ۳ و ۴.)
• در ۲۰۰۹ نخستین پیاده‌سازی عملی سامانهٔ پول الکترونیکی با نام Bitcoin ظاهر شد (واژهٔ cryptocurrency بعداً پیدا شد). برای نخستین بار مسئلهٔ اجماع توزیع‌شده در یک شبکهٔ بدون اعتماد (trustless) حل شد. Bitcoin از رمزنگاری کلید عمومی به‌همراه اثبات کار (Proof of Work, PoW) برای ضرب امن، کنترل‌شده و غیرمتمرکز پول دیجیتال استفاده می‌کند. نوآوری کلیدی: فهرست مرتب‌شدهٔ بلاک‌ها که از تراکنش‌ها تشکیل شده و با PoW از نظر رمزنگاری تضمین می‌شود.
• فناوری‌های دیگری که در Bitcoin به کار رفتند اما از قبل وجود داشتند: درخت مرکل (Merkle tree)، توابع هش و زنجیره‌های هش (hash chains) (فصل ۴).
• جمع‌بندی: بلاک‌چین حاصل ترکیب ایده‌های پول الکترونیکی و سیستم‌های توزیع‌شده است.

بلاک‌چین (پیدایش)

• در ۲۰۰۸ مقاله‌ای انقلابی با عنوان «Bitcoin: A Peer-to-Peer Electronic Cash System» با نام مستعار ساتوشی ناکاموتو (Satoshi Nakamoto) منتشر شد و عبارت «chain of blocks» را معرفی کرد. هویت واقعی او ناشناخته است؛ پس از معرفی Bitcoin در ۲۰۰۹ تا ۲۰۱۱ در جامعهٔ توسعه‌دهندگان فعال بود، سپس توسعه را به هستهٔ توسعه‌دهندگان سپرد و ناپدید شد. عبارت «chain of blocks» به‌مرور به واژهٔ blockchain تبدیل شد.
• بلاک‌چین کاربردهای گسترده‌ای در بخش‌های اقتصادی دارد؛ به‌ویژه در امور مالی انتظار می‌رود زمان و هزینهٔ تراکنش‌ها و تسویه‌ها کاهش یابد (کاربردها در فصل ۱۷).

تعریف بلاک‌چین

• تعریف عامیانه: سیستم ثبت‌رکورد مشترک، امن و همواره‌درحال‌رشد که هر کاربر نسخه‌ای از رکوردها را دارد و فقط وقتی همهٔ طرف‌های ذی‌نفع در تراکنش موافقت کنند به‌روز می‌شود.
• تعریف فنی: یک دفتر کل نظیر‌به‌نظیر (peer-to-peer)، توزیع‌شده، امن از نظر رمزنگاری، فقط‌افزودنی (append-only)، تغییرناپذیر (immutable؛ تغییر آن بسیار دشوار است) و به‌روزرسانی‌پذیر فقط از طریق اجماع (consensus) میان همتایان.

واژه‌های کلیدی تعریف:

• نظیر‌به‌نظیر: کنترل‌کنندهٔ مرکزی وجود ندارد و شرکت‌کنندگان مستقیم با هم ارتباط دارند؛ در نتیجه می‌توان بدون واسطه (مثل بانک) پول مبادله کرد.
• دفتر کل توزیع‌شده: دفتر کل بین همهٔ همتایان پخش است و هر همتا نسخهٔ کامل را دارد.
• امن از نظر رمزنگاری: رمزنگاری خدماتی چون عدم انکار (non-repudiation)، یکپارچگی داده (data integrity) و احراز اصالت مبدأ (data origin authentication) فراهم می‌کند تا دفتر در برابر دست‌کاری و سوءاستفاده ایمن بماند.
• فقط‌افزودنی: داده فقط به‌صورت متوالی و به ترتیب زمانی اضافه می‌شود. تغییر داده‌های ثبت‌شده عملاً غیرممکن است، مگر در سناریوی نادری که تبانی علیه شبکه به کنترل بیش از ۵۱٪ توان دست یابد. گاهی دلایل مشروعی برای تغییر هست (مثل «حق فراموش‌شدن» در GDPR، ماده ۱۷)، اما این موارد فردی‌اند و به راه‌حل فنی ظریف جداگانه نیاز دارند؛ برای همهٔ مقاصد عملی بلاک‌چین تغییرناپذیر است.
• به‌روزرسانی از طریق اجماع: مهم‌ترین ویژگی و منشأ تمرکززدایی. هیچ مرجع مرکزی دفتر را به‌روز نمی‌کند؛ هر تغییر با معیارهای سخت‌گیرانهٔ پروتکل اعتبارسنجی می‌شود و فقط پس از اجماع همهٔ گره‌ها اضافه می‌شود.

نمای شبکه‌ای و کسب‌وکاری

• بلاک‌چین را می‌توان لایه‌ای از یک شبکهٔ نظیر‌به‌نظیر دانست که روی اینترنت اجرا می‌شود؛ مانند SMTP، HTTP یا FTP که روی TCP/IP سوارند. لایه‌ها از پایین: اینترنت ← شبکهٔ P2P ← لایهٔ بلاک‌چین (تراکنش‌ها، بلاک‌ها، سازوکارهای اجماع، ماشین حالت و قراردادهای هوشمند) ← کاربران/گره‌ها که اجماع، تأیید تراکنش و پردازش را انجام می‌دهند.
• از دید کسب‌وکار: پلتفرمی که در آن همتایان ارزش یا پول الکترونیکی را بدون داور مرکزی مورد اعتماد مبادله می‌کنند. در انتقال پول، بانک نقش طرف سوم معتمد دارد و در معاملات مالی، اتاق پایاپای. حذف واسطه (disintermediation) یعنی صرفه‌جویی در هزینه، سرعت بیشتر و اعتماد.

بلاک و اجزای آن

• بلاک مجموعه‌ای از تراکنش‌های منطقی‌سازمان‌یافته است و تراکنش رکورد یک رویداد (مثلاً انتقال پول از حسابی به حساب دیگر). اندازهٔ بلاک بسته به نوع و طراحی بلاک‌چین متفاوت است.
• هر بلاک (به‌جز بلاک پیدایش، genesis block، که اولین بلاک و hardcode شده است) ارجاعی به بلاک قبلی دارد.
• ویژگی‌های ضروری: سرآیند بلاک (block header) شامل اشاره‌گر به بلاک قبلی، برچسب زمانی (timestamp)، nonce و ریشهٔ مرکل (Merkle root)؛ و بدنهٔ بلاک که تراکنش‌ها را در بر دارد.
• Nonce: عددی که فقط یک بار تولید و استفاده می‌شود؛ در رمزنگاری برای حفاظت در برابر تکرار (replay)، احراز هویت و رمزگذاری به کار می‌رود. در بلاک‌چین در PoW و برای محافظت از تراکنش‌ها در برابر replay استفاده می‌شود.
• ریشهٔ مرکل: هش همهٔ گره‌های یک درخت مرکل؛ در سرآیند بلاک قرار دارد. با تأیید فقط ریشه می‌توان همهٔ تراکنش‌ها را بدون بررسی یکی‌یکی تأیید کرد (فصل ۴).

عناصر عمومی یک بلاک‌چین

بلاک‌چین چگونه کار می‌کند

گره‌ها یا ماینر (miner) هستند که بلاک جدید می‌سازند و سکه ضرب می‌کنند، یا امضاکنندهٔ بلاک (block signer) که تراکنش‌ها را اعتبارسنجی و امضا می‌کنند. تصمیم حیاتی هر شبکه این است که کدام گره بلاک بعدی را اضافه کند؛ این تصمیم با سازوکار اجماع گرفته می‌شود.

مراحل انباشت بلاک‌ها

1. گره تراکنشی می‌سازد و با کلید خصوصی خود امضا می‌کند. معمولاً ساختاری داده شامل منطق انتقال ارزش، قوانین، آدرس مبدأ و مقصد و اطلاعات اعتبارسنجی است.
2. تراکنش با پروتکل gossip (flooding) برای همتایان پخش می‌شود و آن‌ها بر اساس معیارهای از پیش‌تعیین‌شده آن را اعتبارسنجی می‌کنند (معمولاً بیش از یک گره).
3. پس از اعتبارسنجی، تراکنش در یک بلاک گنجانده و در شبکه منتشر می‌شود؛ در این نقطه تراکنش «تأییدشده» (confirmed) تلقی می‌شود.
4. بلاک جدید بخشی از دفتر می‌شود و بلاک بعدی با اشاره‌گر هش به آن پیوند می‌خورد؛ تراکنش تأیید دوم و بلاک تأیید اول را می‌گیرد.
5. با ساخته‌شدن هر بلاک جدید تراکنش بازتأیید می‌شود. در Bitcoin معمولاً شش تأیید برای نهایی‌شدن لازم است.

نکته: گام‌های ۴ و ۵ اختیاری شمرده می‌شوند، چون خود تراکنش در گام ۳ نهایی می‌شود؛ تأیید بلاک و بازتأییدها در صورت نیاز انجام می‌شوند.

مزایا و محدودیت‌های بلاک‌چین

مزایا:

• تمرکززدایی: نیاز به واسطهٔ مورد اعتماد نیست؛ اجماع جای اعتبارسنج مرکزی را می‌گیرد.
• شفافیت و اعتماد: چون همه محتوا را می‌بینند، اعتماد ساخته می‌شود؛ به‌ویژه در توزیع کمک‌ها و مزایا که باید سلیقهٔ فردی در انتخاب ذی‌نفعان محدود شود.
• تغییرناپذیری: واقعاً مطلق نیست، اما تغییر داده چنان دشوار است که عملاً یک دفتر تغییرناپذیر فراهم می‌شود.
• دسترس‌پذیری بالا: هزاران گره داده را بازتولید می‌کنند؛ خروج یا از دسترس خارج‌شدن چند گره کل شبکه را متوقف نمی‌کند.
• امنیت بالا: همه تراکنش‌ها رمزنگاری‌شده‌اند و یکپارچگی شبکه را تضمین می‌کنند.
• ساده‌سازی الگوهای موجود: در صنایعی مانند مالی و سلامت، هر نهاد پایگاه دادهٔ خود را دارد و اشتراک داده دشوار است؛ یک دفتر مشترک پیچیدگی مدیریت سیستم‌های جدا را کم می‌کند.
• معاملات سریع‌تر: به‌ویژه در تسویهٔ پس از معامله (post-trade)، چون نسخهٔ واحد توافق‌شده از قبل در دسترس است و فرایند طولانی تأیید، مغایرت‌گیری و پایاپای لازم نیست.
• صرفه‌جویی هزینه: حذف طرف سوم یا اتاق پایاپای هزینه‌های سربار را کاهش می‌دهد.

چالش‌های حساس: مقیاس‌پذیری، قابلیت انطباق/پذیرش (adaptability)، مقررات‌گذاری، نابالغ‌بودن نسبی فناوری و حریم خصوصی (فصل ۱۸).

ردههای (Tier) فناوری بلاک‌چین

این طبقه‌بندی اصلاً از کتاب Blockchain: Blueprint for a New Economy نوشتهٔ Melanie Swan (۲۰۱۵) آمده و در اینجا بیشتر برای کامل‌بودن و دلایل تاریخی ارائه شده است؛ مرزها امروز محو شده و هر پلتفرم قرارداد هوشمند می‌تواند کارکردهای همهٔ ردهها را پیاده کند.

• Machina Economicus مفهومی از هوش مصنوعی و اقتصاد محاسباتی است: ماشینی که تصمیم‌های منطقی و کامل می‌گیرد. چالش‌های فنی فراوانی برای تحقق آن باقی است (بحث همگرایی با AI در فصل ۱۹).

ویژگی‌های بلاک‌چین

بلاک‌چین کارکردهایی مثل انتقال ارزش، مدیریت دارایی‌ها و قراردادها دارد و ویژگی‌ها پشتیبان آن‌اند؛ البته بعضی استثنا دارند (مثلاً Bitcoin قرارداد هوشمند ندارد، و Hyperledger Fabric و MultiChain ارز/توکن تولید نمی‌کنند).

• اجماع توزیع‌شده: شالودهٔ اصلی؛ یک «نسخهٔ واحد از حقیقت» بدون مرجع مرکزی.
• تأیید تراکنش: تراکنش‌های ارسالی بر اساس مجموعه‌قواعدی از پیش‌تعیین‌شده بررسی می‌شوند و فقط تراکنش‌های معتبر وارد بلاک می‌شوند.
• پلتفرم قرارداد هوشمند: برنامه‌های خودکار و خودمختار روی شبکه که منطق کسب‌وکار را وقتی شرایط برقرار شد اجرا می‌کنند. مثال کتاب: بیمهٔ پرواز؛ اگر قرارداد خبر لغو پرواز را از یک منبع دریافت کند، به‌طور خودکار مبلغ بیمه را به مسافر می‌پردازد، و اگر پرواز به‌موقع باشد، پول در قرارداد می‌ماند. این یعنی انعطاف، سرعت، امنیت و اتوماسیون با اعتماد رمزنگاری‌شده (و نیاز به یک خوراک داده، که در فصل ۹ با اوراکل توضیح داده می‌شود).
• انتقال ارزش بین همتایان: از طریق توکن (حامل ارزش).
• تولید ارز رمزنگاری‌شده: اختیاری؛ برای تشویق ماینرهایی که تراکنش‌ها را تأیید می‌کنند و منابع صرف امنیت می‌کنند.
• دارایی هوشمند (smart property): می‌توان دارایی دیجیتال یا فیزیکی را چنان به بلاک‌چین پیوند داد که کسی دیگر نتواند ادعای مالکیت کند؛ دوبار خرج یا دو مالکی نمی‌شود. مقایسه با فایل موسیقی که بی‌کنترل کپی می‌شود: طرح‌های مدیریت حقوق دیجیتال (DRM) متعددی شکسته شده‌اند (مثلاً هک Oculus و PS3)، اما DRM مبتنی بر بلاک‌چین به‌طور کامل قابل اِعمال است. مسئلهٔ خرج مضاعف نخستین بار در Bitcoin بدون طرف سوم حل شد.
• ارائه‌دهندهٔ امنیت: رمزنگاری اثبات‌شده، یکپارچگی و دسترس‌پذیری داده را تضمین می‌کند؛ اما به‌دلیل نیاز به شفافیت معمولاً محرمانگی (confidentiality) ندارد، که مانع بزرگ پذیرش برای مؤسسات مالی است؛ تحقیقات برای حریم خصوصی فعال است (مثلاً Zcash برای تراکنش ناشناس، فصل ۸). عدم انکار و احراز هویت با کلید خصوصی و امضای دیجیتال فراهم می‌شود.
• تغییرناپذیری: برگرداندن تغییرات از نظر نظری ممکن اما بسیار پرهزینه است؛ مثلاً در Bitcoin دستکاری بلاک‌های قبلی یعنی محاسبهٔ دوبارهٔ PoW برای همهٔ بلاک‌های بعدی.
• یکتایی: هر تراکنش یکتاست و پیش‌تر خرج نشده (جلوگیری از double-spend).

انواع بلاک‌چین

این دسته‌بندی با «ردهها» (Tier) متفاوت است و هر نوع می‌تواند در هر رده‌ای باشد.

• دفتر کل توزیع‌شده (Distributed ledger): اصطلاحی عام برای پایگاه‌های داده مشترک؛ همهٔ بلاک‌چین‌ها دفتر کل توزیع‌شده‌اند، اما عکس آن درست نیست؛ دفتر توزیع‌شده لزوماً از بلاک‌های تراکنش ساخته نشده است. مثال: Corda از R3 که برای ثبت و مدیریت توافق‌ها (به‌ویژه مالی) ساخته شده و بلاک ندارد؛ Ripple هم رکوردها را پیوسته نگه می‌دارد. دفتر توزیع‌شده می‌تواند خصوصی یا عمومی باشد.
• فناوری دفتر کل توزیع‌شده (DLT): در بخش مالی این واژه اغلب مترادف بلاک‌چین به کار می‌رود (هرچند کاملاً دقیق نیست). از دید بخش مالی، DLTها بلاک‌چین‌های مجوزدار (permissioned) میان شرکت‌کنندگان شناخته‌شده و تأییدشده‌اند، اغلب بدون ارز رمزنگاری‌شده و بدون نیاز به ماینینگ.
• بلاک‌چین عمومی (Public): مالک ندارد، بدون مجوز (permissionless)، هر کس می‌تواند گره باشد و در تصمیم‌گیری شرکت کند؛ ممکن است پاداش بگیرد. هر گره نسخهٔ محلی دارد و با اجماع توزیع‌شده حالت نهایی تعیین می‌شود. نمونه: Bitcoin و Ethereum.
• بلاک‌چین خصوصی (Private): فقط برای کنسرسیوم یا گروهی که تصمیم به اشتراک‌گذاری دفتر دارند؛ مثل HydraChain و Quorum (که اختیاراً می‌توانند در حالت عمومی هم اجرا شوند).
• بلاک‌چین نیمه‌خصوصی (Semiprivate): بخشی خصوصی (تحت کنترل یک گروه) و بخشی عمومی (باز برای همه، با امکان ماینینگ برای تأمین امنیت با PoW)؛ هنوز مفهومی است و اثبات مفهوم واقعی ندارد. می‌توان آن را مدل نیمه‌غیرمتمرکز نامید.
• زنجیرهٔ جانبی (Sidechain، دقیق‌تر: pegged sidechain): امکان انتقال سکه از یک بلاک‌چین به دیگری و بازگشت. کاربرد: ساخت آلت‌کوین‌های جدید با سوزاندن (burn) سکه‌ها (ارسال به آدرس غیرقابل خرج) به‌عنوان اثبات سهم کافی؛ این سازوکار اثبات سوزاندن (Proof of Burn, PoB) نام دارد و جایگزینی برای PoW و PoS است. انواع: یک‌طرفه (one-way peg) و دوطرفه (two-way peg). Rootstock نمونهٔ برجسته‌ای است که با peg دوطرفه قرارداد هوشمند را برای Bitcoin ممکن و توان عملیاتی را بیشتر می‌کند.
• دفتر مجوزدار (Permissioned ledger): شرکت‌کنندگان از پیش شناخته و مورد اعتمادند؛ به اجماع توزیع‌شده نیاز نیست و یک پروتکل توافق (agreement) کافی است؛ اعتبارسنج‌ها از پیش توسط مرجعی انتخاب شده‌اند و ماینینگ لازم نیست. لزوماً خصوصی هم نیست؛ مثلاً Bitcoin با افزودن لایهٔ کنترل دسترسی و احراز هویت می‌تواند مجوزدار شود.
• دفتر مشترک (Shared ledger): اصطلاحی عام برای هر برنامه یا پایگاه دادهٔ مشترک بین عموم یا کنسرسیوم؛ تقریباً همهٔ بلاک‌چین‌ها در این دسته‌اند.
• بلاک‌چین کاملاً خصوصی و اختصاصی: کاربرد جریان اصلی ندارد، چون با تمرکززدایی فاصله دارد؛ ولی درون یک سازمان (مثلاً همکاری وزارتخانه‌های یک دولت) می‌تواند برای اشتراک داده با تضمین اصالت مفید باشد. به اجماع پیچیده نیاز نیست؛ تکثیر ماشین حالت و پروتکل توافق با اعتبارسنج‌های مرکزی کافی است.
• بلاک‌چین توکن‌دار (Tokenized): ارز رمزنگاری‌شده را از طریق اجماع (ماینینگ یا توزیع اولیه) تولید می‌کند؛ مثل Bitcoin و Ethereum.
• بلاک‌چین بدون توکن (Tokenless): واحد پایه‌ای انتقال ارزش ندارد؛ برای اشتراک داده بین طرف‌های مورد اعتماد مفید است و از تغییرناپذیری، امنیت و به‌روزرسانی مبتنی بر اجماع بهره می‌برد.

اجماع (Consensus)

اجماع ستون فقرات بلاک‌چین است و تمرکززدایی کنترل را از طریق فرایند اختیاری ماینینگ فراهم می‌کند. انتخاب الگوریتم به نوع بلاک‌چین بستگی دارد؛ مثلاً در شبکهٔ عمومی بدون مجوز PoW منطقی‌تر است تا توافق ساده‌ای مبتنی بر proof of authority.

• اجماع: فرایند توافق میان گره‌های بی‌اعتماد بر حالت نهایی داده. توافق بین دو گره (مثل client-server) ساده است؛ اما وقتی گره‌های زیادی باید روی یک مقدار توافق کنند، دشوار می‌شود. توافق مشترک با وجود خرابی برخی گره‌ها اجماع توزیع‌شده نام دارد.
• سازوکار اجماع: مجموعه گام‌هایی که اکثر یا همهٔ گره‌ها برای توافق بر یک حالت یا مقدار پیشنهادی برمی‌دارند؛ بیش از سه دهه موضوع پژوهش بوده و با Bitcoin به صحنه آمده است.

الزامات سازوکار اجماع

دو دستهٔ کلی اجماع (دیدگاه سیستم‌های توزیع‌شده)

• مبتنی بر BFT سنتی: بدون عملیات سنگین محاسباتی (مثل وارونه‌کردن جزئی هش در PoW)؛ مبتنی بر پیام‌های امضاشدهٔ گره‌ها و رسیدن به توافق پس از دریافت تعداد معینی پیام.
• مبتنی بر انتخاب رهبر (leader election): گره‌ها در یک قرعه‌کشی برای رهبری رقابت می‌کنند و برنده مقدار نهایی را پیشنهاد می‌دهد؛ مثل PoW در Bitcoin.

پروتکل‌های عملی مطرح:

• Paxos: معرفی‌شده توسط Leslie Lamport در ۱۹۸۹؛ نقش‌ها: Proposer، Acceptor، Learner؛ گره‌ها را replica می‌نامند و اجماع با توافق اکثریت و با وجود گره‌های معیوب حاصل می‌شود.
• RAFT: جایگزین Paxos؛ سه حالت follower، candidate و leader؛ رهبر پس از گرفتن رأی کافی انتخاب می‌شود، همهٔ تغییرات از طریق او می‌گذرد و پس از تکثیر روی اکثریت followerها آن‌ها را commit می‌کند.

اجماع در بلاک‌چین

دو دستهٔ اصلی:

• مبتنی بر اثبات / قرعه‌کشی انتخاب رهبر / اجماع ناکاموتو: رهبر به‌طور تصادفی (با الگوریتم) انتخاب می‌شود و مقدار نهایی را پیشنهاد می‌دهد؛ مناسب مدل کاملاً غیرمتمرکز و بدون مجوز؛ PoW در Bitcoin و Ethereum.
• مبتنی بر BFT: رویکرد سنتی‌تر با دورهای رأی‌گیری؛ مناسب مدل کنسرسیومی/مجوزدار.

مقایسه: BFT با تعداد گرهٔ محدود خوب عمل می‌کند اما مقیاس‌پذیر نیست؛ اجماع لاتاری (PoW) خوب مقیاس می‌پذیرد اما کند است. مدل‌های نوظهور برای ایجاد تعادل میان مقیاس‌پذیری و کارایی پیشنهاد شده‌اند، مانند مدل نیمه‌غیرمتمرکز در شبکهٔ Ripple (فصل ۱۶) و PBFT، Hybrid BFT، BlockDAG، Tezos، Stellar و GHOST.

فهرست الگوریتم‌های اجماع (غیرجامع)

قضیهٔ CAP و بلاک‌چین

• قضیهٔ CAP (قضیهٔ Brewer): ابتدا در ۱۹۹۸ توسط Eric Brewer به‌صورت حدس مطرح شد و در ۲۰۰۲ Seth Gilbert و Nancy Lynch آن را اثبات کردند. هر سیستم توزیع‌شده نمی‌تواند هر سه ویژگی زیر را همزمان داشته باشد:
  • سازگاری (Consistency): همهٔ گره‌ها یک نسخهٔ واحد، به‌روز و یکسان از داده دارند.
  • دسترس‌پذیری (Availability): گره‌ها بالا هستند و به درخواست‌ها پاسخ می‌دهند.
  • تحمل افراز (Partition tolerance): اگر گروهی از گره‌ها به‌دلیل نقص شبکه با بقیه ارتباط نداشته باشند، سیستم همچنان درست کار کند.
• مثال دو گره: اگر افراز رخ دهد و به‌روزرسانی فقط به یک گره برسد، پذیرفتن آن سازگاری را از بین می‌برد و رد کردن آن دسترس‌پذیری را؛ پس با داشتن تحمل افراز نمی‌توان هر دو را داشت.
• به‌نظر می‌رسد بلاک‌چین (به‌ویژه Bitcoin) این قضیه را نقض می‌کند، اما چنین نیست: در بلاک‌چین سازگاری فدای دسترس‌پذیری و تحمل افراز می‌شود و در طول زمان حاصل می‌گردد؛ این سازگاری نهایی (eventual consistency) است که از اعتبارسنجی چندین گره در طی زمان به دست می‌آید. ماینینگ در Bitcoin برای همین هدف است: فرایندی که با PoW به رسیدن اجماع کمک می‌کند و بلاک‌های بیشتری به زنجیره اضافه می‌کند.
• تحمل خطا با تکثیر (replication) به دست می‌آید و سازگاری با الگوریتم‌های اجماع (تکثیر ماشین حالت)؛ بلاک‌چین ابزاری برای state machine replication است.
• دو نوع خطای گره:
  • خطای توقف (fail-stop): گره صرفاً از کار افتاده؛ ساده‌تر و معمولاً با Paxos مدیریت می‌شود.
  • خطای بیزانسی: گره رفتار دلخواه، بدخواهانه یا ناسازگار نشان می‌دهد؛ ناشی از حمله، باگ نرم‌افزاری یا خرابی داده؛ سخت‌تر است و پروتکل‌های تکثیر ماشین حالت مانند PBFT برای آن ساخته شده‌اند.

جمع‌بندی

فصل اول با مبانی سیستم‌های توزیع‌شده (گره، مسئلهٔ ژنرال‌های بیزانسی، تحمل خطا و قضیهٔ CAP) آغاز می‌شود، سپس ریشه‌های تاریخی بلاک‌چین را در پول الکترونیکی چام و اختراع Bitcoin توسط ساتوشی ناکاموتو دنبال می‌کند. تعریف بلاک‌چین (دفتر کل نظیر‌به‌نظیر، توزیع‌شده، امن، فقط‌افزودنی، تغییرناپذیر و به‌روزرسانی‌شونده با اجماع)، اجزای عمومی آن (آدرس، تراکنش، بلاک، شبکه، اسکریپت، ماشین مجازی، گره و قرارداد هوشمند) و روند گام‌به‌گام ساخت بلاک و تأییدها شرح داده می‌شود. سپس مزایا (تمرکززدایی، شفافیت، تغییرناپذیری، دسترس‌پذیری، امنیت، سرعت و صرفه‌جویی هزینه) و چالش‌ها (مقیاس‌پذیری، پذیرش، مقررات، بلوغ و حریم خصوصی)، ردهای 1.0 تا X.0، ویژگی‌ها و انواع بلاک‌چین (عمومی، خصوصی، مجوزدار، DLT، sidechain و غیره) بررسی می‌شود. در پایان، الزامات و انواع الگوریتم‌های اجماع (از PoW و PoS تا PBFT، Paxos و RAFT) مرور شده و توضیح داده می‌شود که بلاک‌چین با انتخاب «سازگاری نهایی» از محدودیت CAP عبور نمی‌کند، بلکه با آن کنار می‌آید. فصل بعد به مفهوم تمرکززدایی می‌پردازد.

فصل ۲ — تمرکززدایی (Decentralization)

مقدمه

تمرکززدایی (Decentralization) مفهومی تازه نیست؛ سال‌هاست در استراتژی، مدیریت و حکمرانی به کار می‌رود. ایدهٔ پایه این است که کنترل و اختیار به لبه‌ها و بخش‌های پیرامونی یک سازمان سپرده شود، نه اینکه یک مرکز واحد همه‌چیز را در دست داشته باشد. حاصل این چیدمان برای سازمان‌ها معمولاً کارایی بیشتر، تصمیم‌گیری سریع‌تر، انگیزهٔ بهتر کارکنان و کاهش بار مدیریت ارشد است.

این فصل تمرکززدایی را در بستر بلاک‌چین بررسی می‌کند: پایهٔ بلاک‌چین این است که هیچ مرجع مرکزی واحدی کنترل را در دست ندارد. فصل به ترتیب به این موضوع‌ها می‌پردازد: روش‌ها و مسیرهای رسیدن به تمرکززدایی، تمرکززدایی کل اکوسیستم پیرامون بلاک‌چین (ذخیره‌سازی، ارتباطات، محاسبات، هویت)، مفاهیمی مانند قرارداد هوشمند، DO، DAO، DAC و DAS، برنامه‌های غیرمتمرکز (DApp) و در پایان چند پلتفرم رایج.

تمرکززدایی با استفاده از بلاک‌چین

• بلاک‌چین از اساس بستری است که واسطه نمی‌خواهد و می‌تواند با چندین «رهبر» که از راه سازوکار اجماع انتخاب می‌شوند کار کند. هر کس می‌تواند برای تبدیل‌شدن به مرجع تصمیم‌گیر رقابت کند و این رقابت را اجماع (رایج‌ترین آن اثبات کار، PoW) تنظیم می‌کند.
• تمرکززدایی طیفی است: از مدل نیمه‌غیرمتمرکز تا کاملاً غیرمتمرکز، بسته به نیاز و شرایط. از دید بلاک‌چین، این ابزار راهی برای بازطراحی برنامه‌ها و الگوهای موجود یا ساخت برنامه‌های نو است که کنترل کامل را به کاربران می‌دهد.
• فناوری اطلاعات و ارتباطات (ICT) سنتی بر الگوی متمرکز بنا شده بود: سرورهای پایگاه داده و برنامه زیر نظر یک مرجع مثل مدیر سیستم. با بیت‌کوین و بلاک‌چین، امکان راه‌اندازی سیستمی بدون نقطهٔ شکست واحد (single point of failure) و بدون مرجع معتمد واحد پدید آمد؛ این سیستم می‌تواند خودکار کار کند یا بسته به مدل حکمرانی نیازمند دخالت انسانی باشد.

سه نوع سیستم: متمرکز، غیرمتمرکز، توزیع‌شده

مفهوم این سه نوع شبکه را Paul Baran در گزارش سال ۱۹۶۴ مؤسسهٔ RAND دربارهٔ ارتباطات توزیع‌شده مطرح کرد.

نکات تکمیلی:

• محاسبات توزیع‌شده را نباید با محاسبات موازی (parallel computing) یکی گرفت. در موازی، همهٔ گره‌ها هم‌زمان در محاسبه شرکت می‌کنند (مثل پیش‌بینی هوا، شبیه‌سازی و مدل‌سازی مالی) و باز هم یک مرجع مرکزی بر پردازش نظارت دارد؛ پس ماهیتاً متمرکز است. در توزیع‌شده لزوماً محاسبه موازی نیست و داده روی چند گره تکرار می‌شود.
• تمایز کلیدی: در سیستم توزیع‌شده هنوز مرجعی مرکزی هست، ولی در سیستم غیرمتمرکز نیست. تشبیه کتاب: هر بخش سازمان پایگاه داده و سرور خودش را اداره کند و قدرت از سرور مرکزی به زیرمجموعه‌ها منتقل شود.
• نوآوری اصلی این الگو اجماع غیرمتمرکز (decentralized consensus) است که با بیت‌کوین آمد و امکان توافق بر سر یک موضوع را بدون شخص ثالث معتمد، واسطه یا ارائه‌دهندهٔ خدمت فراهم می‌کند.

روش‌های تمرکززدایی

دو روش برای رسیدن به تمرکززدایی وجود دارد: حذف واسطه (Disintermediation) و تمرکززدایی رقابت‌محور (Contest-driven).

حذف واسطه

مثال کتاب: ارسال پول به دوستی در کشور دیگر. در روش سنتی به بانک مراجعه می‌کنید و بانک با دریافت کارمزد، پایگاه داده‌ای مرکزی را به‌روز می‌کند و پول را به بانک مقصد می‌رساند. با بلاک‌چین کافی است آدرس دوستتان را داشته باشید و پول مستقیماً منتقل شود؛ بانک دیگر لازم نیست. البته عملی‌بودن این حذف واسطه در بخش مالی به‌دلیل الزامات سنگین قانونی و انطباق محل بحث است، اما این الگو در صنایع دیگر هم کاربرد دارد.

تمرکززدایی رقابت‌محور

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

مقیاس تمرکززدایی

شکل کتاب سه سطح را نشان می‌دهد: در یک سو سیستم متمرکز سنتی، در سوی دیگر حذف کامل واسطه‌ها، و در میانه واسطه‌های رقیب که بر پایهٔ شهرت یا رأی‌گیری انتخاب می‌شوند (تمرکززدایی جزئی).

مزایای تمرکززدایی: شفافیت، کارایی، صرفهٔ هزینه، ساخت اکوسیستم‌های مورد اعتماد و در برخی موارد حریم خصوصی و ناشناسی. چالش‌ها: الزامات امنیتی، باگ نرم‌افزار و خطای انسانی. مثال: در بیت‌کوین یا اتریوم امنیت وابسته به کلید خصوصی است؛ اگر کلید گم شود یا باگ قرارداد هوشمند باعث آسیب‌پذیری شود، دارایی مرتبط عملاً از کار می‌افتد. پس هر چیزی را نمی‌توان یا نباید غیرمتمرکز کرد.

آیا واقعاً به بلاک‌چین نیاز دارید؟

مجموعهٔ پرسش‌های ساده برای تصمیم‌گیری میان بلاک‌چین و پایگاه داده سنتی:

1. آیا گذردهی (throughput) بالای داده لازم است؟ اگر بله، پایگاه داده سنتی.
2. آیا به‌روزرسانی‌ها به‌صورت مرکزی کنترل می‌شود؟ اگر بله، پایگاه داده سنتی.
3. آیا کاربران به هم اعتماد دارند؟ اگر بله، پایگاه داده سنتی.
4. آیا کاربران ناشناس‌اند؟ اگر بله، بلاک‌چین عمومی؛ اگر نه، بلاک‌چین خصوصی.
5. آیا اجماع باید درون یک کنسرسیوم حفظ شود؟ اگر بله، بلاک‌چین خصوصی؛ وگرنه عمومی.

ملاحظات بیشتر: تأخیر (latency)، انتخاب سازوکار اجماع، اینکه اصلاً اجماع لازم است یا نه و کجا برقرار می‌شود. اگر اجماع درون کنسرسیوم باشد، بلاک‌چین خصوصی مناسب است و اگر میان نهادهای متعدد به‌صورت عمومی لازم باشد، بلاک‌چین عمومی. اگر تغییرناپذیری (immutability) سخت‌گیرانه لازم باشد، بلاک‌چین عمومی؛ وگرنه شاید پایگاه داده مرکزی کافی باشد.

مسیرهای تمرکززدایی

پیش از بلاک‌چین هم سیستم‌هایی مثل BitTorrent و شبکهٔ اشتراک فایل Gnutella تا حدی غیرمتمرکز بودند. اکنون بلاک‌چین بیت‌کوین برای بسیاری نخستین انتخاب است، چون مقاوم‌ترین و امن‌ترین زنجیره شناخته می‌شود (ارزش بازار نزدیک ۱۴۵ میلیارد دلار در زمان نگارش کتاب). اتریوم به‌دلیل انعطاف در برنامه‌ریزی هر منطق کسب‌وکاری با قرارداد هوشمند، ابزار محبوب توسعه‌دهندگان DApp است.

چگونه تمرکززدایی کنیم؟ (چارچوب Narayanan)

Arvind Narayanan و همکاران در کتاب Bitcoin and Cryptocurrency Technologies (دانشگاه Princeton) چارچوبی با چهار پرسش ارائه داده‌اند:

1. چه چیزی غیرمتمرکز می‌شود؟ (مثلاً سیستم هویت یا معاملات)
2. چه سطحی از تمرکززدایی لازم است؟ (حذف کامل یا جزئی واسطه)
3. از کدام بلاک‌چین استفاده می‌شود؟ (بیت‌کوین، اتریوم یا غیر آن)
4. چه سازوکار امنیتی به کار می‌رود؟ مثلاً بر پایهٔ اتمیک بودن (atomicity: تراکنش یا کامل اجرا می‌شود یا اصلاً اجرا نمی‌شود) که رویکردی قطعی و حافظ یکپارچگی است، یا بر پایهٔ شهرت که درجات متفاوتی از اعتماد می‌دهد.

مثال چارچوب: سیستم انتقال پول: (۱) سیستم انتقال پول، (۲) حذف واسطه، (۳) بیت‌کوین، (۴) اتمیک بودن. یعنی سیستم با حذف واسطه، روی بلاک‌چین بیت‌کوین (قدیمی‌ترین و آزموده‌ترین زنجیره) و با ضمانت اتمیک بودن تراکنش‌ها غیرمتمرکز می‌شود.

تمرکززدایی بلاک‌چین و کل اکوسیستم

برای تمرکززدایی کامل، محیط پیرامون بلاک‌چین هم باید غیرمتمرکز باشد؛ چون بلاک‌چین دفتر کل توزیع‌شده‌ای است که روی سیستم‌های متعارف اجرا می‌شود. این محیط شامل ذخیره‌سازی، ارتباطات و محاسبات است، به‌علاوهٔ هویت و ثروت که سنتی متمرکزند.

ذخیره‌سازی

• داده را می‌توان مستقیم روی بلاک‌چین گذاشت، اما بلاک‌چین برای ذخیرهٔ حجم زیاد (تصویر و فایل بزرگ) طراحی نشده است؛ فقط تراکنش‌های ساده و کمی داده دلخواه.
• جایگزین بهتر جداول هش توزیع‌شده (Distributed Hash Tables, DHT) است که در نرم‌افزارهای اشتراک فایل همتابه‌همتا مثل BitTorrent، Napster، Kazaa و Gnutella استفاده می‌شد و پژوهش‌های CAN، Chord، Pastry و Tapestry آن را مشهور کردند. مشکل: BitTorrent سریع و مقیاس‌پذیر است ولی انگیزه‌ای برای نگه‌داشتن دائمی فایل‌ها وجود ندارد و اگر گره‌های دارندهٔ داده شبکه را ترک کنند، بازیابی ممکن نیست.
• دو نیاز اصلی: دسترس‌پذیری بالا و پایداری پیوند. پروژهٔ IPFS (InterPlanetary File System) از Juan Benet هر دو را دارد و هدفش جایگزینی HTTP و ساخت وب جهانی غیرمتمرکز است. IPFS از Kademlia DHT برای ذخیره و از Merkle DAG (گراف جهت‌دار بدون دور) برای جست‌وجو استفاده می‌کند (DHT و DAG در فصل ۴ می‌آید).
• انگیزهٔ ذخیره بر پروتکل Filecoin استوار است که به گره‌های ذخیره‌کنندهٔ داده با سازوکار Bitswap پاداش می‌دهد؛ Bitswap یک دفتر ساده از بایت‌های ارسالی/دریافتی میان هر دو همتا نگه می‌دارد. IPFS همچنین از کنترل نسخهٔ مبتنی بر Git برای نسخه‌بندی داده بهره می‌برد.
• گزینه‌های دیگر: Ethereum Swarm، Storj و MaidSafe. اتریوم اکوسیستم خود را دارد: Swarm برای ذخیره و پروتکل Whisper برای ارتباط. MaidSafe وب جهانی غیرمتمرکز را هدف گرفته است.
• BigchainDB لایهٔ ذخیره‌سازی دیگری است: پایگاه داده‌ای غیرمتمرکز، سریع و با مقیاس‌پذیری خطی (نه سیستم فایل) که مکمل پلتفرم‌های پردازشی مثل اتریوم و سیستم فایلی مثل IPFS است.

ارتباطات

• اینترنت (لایهٔ ارتباطی بلاک‌چین) تا حدی غیرمتمرکز شناخته می‌شود، چون چشم‌انداز اولیه‌اش همین بود. اما امروز خدماتی مثل ایمیل و ذخیرهٔ آنلاین بر پایهٔ اعتماد بی‌قیدوشرط به ارائه‌دهنده‌اند؛ کاربر کنترل داده‌اش را ندارد و حتی گذرواژه‌ها نزد شخص ثالث ذخیره می‌شود.
• دسترسی به اینترنت وابسته به ارائه‌دهندگان خدمات اینترنت (ISP) است که مانند هاب مرکزی عمل می‌کنند؛ با از کار افتادن ISP ارتباط قطع می‌شود.
• جایگزین: شبکه‌های مش (mesh networks) که با وجود امکانات محدودتر، گره‌ها را مستقیم به هم وصل می‌کنند. نمونه: برنامهٔ FireChat که کاربران iPhone را بدون اینترنت و به‌صورت همتابه‌همتا به هم مرتبط می‌کند. چنین مدلی بیشتر در کشورهایی که اینترنت سانسور و کنترل می‌شود حیاتی است.
• با وجود ماهیت غیرمتمرکز ایمیل (هر کس می‌تواند سرور ایمیل راه بیندازد)، راحتی و رایگان‌بودن Gmail و Outlook.com کاربران را به سمت خدمات متمرکز برده است؛ و رایگان‌بودن به قیمت در معرض قرارگرفتن داده‌های شخصی تمام می‌شود. بلاک‌چین این چشم‌انداز را دوباره زنده کرده است.

قدرت محاسباتی

تمرکززدایی پردازش با بلاک‌چینی مثل اتریوم محقق می‌شود که قراردادهای هوشمند حاوی منطق کسب‌وکار روی شبکه اجرا می‌شوند. سایر پلتفرم‌ها هم لایهٔ پردازشی مشابه دارند.

نمای کلی اکوسیستم غیرمتمرکز

لایه‌ها از پایین به بالا:

بلاک‌چین می‌تواند محدود ذخیره‌سازی هم بدهد، اما سرعت و ظرفیت را به‌شدت کاهش می‌دهد؛ پس IPFS و BigchainDB مناسب‌ترند.

مثلث Zooko و Namecoin

مثلث Zooko می‌گوید سیستم نام‌گذاری در یک پروتکل شبکه باید هم امن، هم غیرمتمرکز و هم دارای نام‌های معنادار و به‌یادماندنی برای انسان باشد، اما حدس این است که فقط دو ویژگی از سه را می‌توان هم‌زمان داشت. بلاک‌چین Namecoin نشان داد هر سه ممکن است. البته این نسخهٔ شفابخش نیست: کاربر باید کلید خصوصی را خودش امن نگه دارد.

تمرکززدایی برای هر سناریویی مناسب نیست؛ سیستم‌های متمرکز با شهرت خوب اغلب بهتر کار می‌کنند. مثلاً ایمیل Google یا Microsoft به سرورهای ایمیل پراکندهٔ شخصی ترجیح دارد. پروژه‌هایی مانند Swarm و Whisper برای تکمیل اکوسیستم اتریوم در حال توسعه‌اند (فصل ۱۱).

مفاهیم مرتبط با تمرکززدایی

قراردادهای هوشمند

قرارداد هوشمند (smart contract) یک برنامهٔ غیرمتمرکز است. لزوماً به بلاک‌چین نیاز ندارد، اما به‌دلیل مزایای امنیتی بلاک‌چین، بستر اجرایی استاندارد آن شده است. معمولاً شامل منطق کسب‌وکار و مقدار محدودی داده است و منطق وقتی معیارهای مشخص برآورده شود اجرا می‌شود؛ شرکت‌کنندگان از آن استفاده می‌کنند یا خودمختار به نمایندگی از آنان کار می‌کند (جزئیات در فصل ۹).

سازمان‌های غیرمتمرکز (DO)

DO (Decentralized Organization) برنامه‌ای است که روی بلاک‌چین اجرا می‌شود و بر ایدهٔ سازمان واقعی با افراد و پروتکل‌ها استوار است. پس از افزوده‌شدن به بلاک‌چین (به‌صورت یک یا چند قرارداد هوشمند)، طرف‌ها بر اساس کد درون آن با هم تعامل می‌کنند.

سازمان‌های خودمختار غیرمتمرکز (DAO)

• DAO (Decentralized Autonomous Organization) در اصل همان DO است، با این تفاوت که کاملاً خودکار است و منطق هوشمند دارد، در حالی که DO برای اجرای منطق به ورودی انسان نیاز دارد.
• اتریوم پیشگام DAO بود. در DAO «کد» نهاد حاکم است، نه افراد یا قراردادهای کاغذی؛ هرچند یک متولی (curator) انسانی کد را نگه می‌دارد و پیشنهادها را برای جامعه ارزیابی می‌کند. DAO می‌تواند در صورت ورودی کافی از دارندگان توکن، پیمانکار بیرونی استخدام کند.
• مشهورترین نمونه The DAO است که در جمع‌آوری سرمایه ۱۶۸ میلیون دلار جذب کرد؛ صندوق سرمایه‌گذاری مخاطره‌آمیز بدون مالک واحد. به‌دلیل باگ کد هک شد و میلیون‌ها دلار اتر به یک child DAO مهاجم منتقل شد. برای خنثی‌کردن آن لازم شد روی اتریوم هارد فورک انجام شود. این رخداد بحث دربارهٔ امنیت، کیفیت و ضرورت آزمون دقیق کد قرارداد هوشمند را داغ کرد و پژوهش‌هایی (به‌ویژه دانشگاهی) برای صوری‌سازی کدنویسی و آزمون قراردادها در جریان است.
• DAOها فعلاً جایگاه قانونی ندارند و قواعد درون کدشان در نظام حقوقی دنیای واقعی ارزش ندارد. شاید روزی یک عامل خودمختار (Autonomous Agent) از سوی نهاد قانون‌گذار، قواعد را در DAO قرار دهد. چون DAO در هر حوزهٔ قضایی می‌تواند اجرا شود، اعمال قانون موجود بر چنین ترکیب پراکنده‌ای پرسش بزرگی است.

شرکت‌های خودمختار غیرمتمرکز (DAC)

DAC مفهوماً شبیه DAO و زیرمجموعهٔ کوچک‌تر آن دانسته می‌شود. تفاوت متداول: DAO معمولاً غیرانتفاعی است، اما DAC می‌تواند سود کسب کند، سهام به شرکت‌کنندگان بدهد و سود سهام بپردازد، و بر اساس منطق برنامه‌ریزی‌شده کسب‌وکار را بدون دخالت انسان اداره کند.

جوامع خودمختار غیرمتمرکز (DAS)

DAS یعنی کارکرد یک جامعهٔ کامل روی بلاک‌چین با کمک قراردادهای هوشمند پیچیده و ترکیب DAO و DApp. این لزوماً هرج‌ومرج یا ایدئولوژی لیبرتارین محض نیست؛ بسیاری از خدمات دولتی مثل کارت شناسایی، گذرنامه و ثبت اسناد مالکیت، ازدواج و تولد می‌تواند روی بلاک‌چین ارائه شود. یک نظریه هم این است که اگر دولتی فاسد باشد و سیستم‌های مرکزی اعتماد کافی ندهند، جامعه می‌تواند جامعهٔ مجازی خودش را بر پایهٔ اجماع غیرمتمرکز و شفافیت راه بیندازد.

برنامه‌های غیرمتمرکز (DApp)

همهٔ مفاهیم بالا زیر چتر DApp قرار می‌گیرند. DAO، DAC و DO خودشان DApp‌هایی هستند که روی بلاک‌چین در شبکهٔ همتابه‌همتا اجرا می‌شوند. DAppها نرم‌افزارهایی‌اند که می‌توانند بلاک‌چین اختصاصی خود را داشته باشند (نوع I)، از بلاک‌چین مستقر موجود استفاده کنند (نوع II) یا فقط از پروتکل‌های یک بلاک‌چین موجود بهره ببرند (نوع III).

الزامات یک DApp

بر پایهٔ تعریف مقالهٔ Johnston و همکاران (The General Theory of Decentralized Applications, Dapps):

• کاملاً متن‌باز و خودمختار باشد؛ هیچ نهادی اکثریت توکن‌هایش را کنترل نکند؛ تغییرات بر اساس اجماع و بازخورد جامعه باشد.
• داده و سوابق عملیات به‌صورت رمزنگاری‌شده روی یک بلاک‌چین عمومی غیرمتمرکز ذخیره شود تا نقطهٔ شکست مرکزی نباشد.
• از یک توکن رمزنگاری‌شده برای دسترسی و پاداش دادن به مشارکت‌کنندگان ارزش (مثل ماینرها در بیت‌کوین) استفاده کند.
• توکن‌ها طبق یک الگوریتم رمزنگاری استاندارد توسط خود DApp تولید شوند و تولیدشان گواه ارزش مشارکت باشد.

عملکرد DApp

اجماع می‌تواند با الگوریتم‌هایی مثل PoW و اثبات سهام (PoS) برقرار شود؛ تا زمان کتاب فقط PoW در برابر حملهٔ ۵۱٪ بسیار مقاوم بوده است (چنانکه بیت‌کوین نشان می‌دهد). توزیع توکن می‌تواند از راه ماینینگ، جمع‌آوری سرمایه و توسعه انجام شود.

نمونه‌های DApp

• KYC-Chain: مدیریت امن و راحت داده‌های «احراز هویت مشتری» (KYC) بر پایهٔ قرارداد هوشمند.
• OpenBazaar: شبکهٔ همتابه‌همتا برای تجارت مستقیم میان خریدار و فروشنده بدون واسطه‌ای مثل eBay یا Amazon. این سیستم روی بلاک‌چین ساخته نشده؛ از DHT برای ارتباط و اشتراک داده بهره می‌برد و برای پرداخت از بیت‌کوین و ارزهای دیگر استفاده می‌کند.
• Lazooz: معادل غیرمتمرکز Uber برای اشتراک سفر همتابه‌همتا که با «اثبات حرکت» (proof of movement) به کاربران سکهٔ Zooz می‌دهد.

DAppهای بسیار دیگری روی اتریوم ساخته شده‌اند (فهرست در سایت ethercasts).

پلتفرم‌های تمرکززدایی

هر شبکهٔ بلاک‌چین (بیت‌کوین، اتریوم، Hyperledger Fabric، Quorum) می‌تواند خدمت تمرکززدایی بدهد. چند پلتفرم:

معرفی عملی‌تر این پلتفرم‌ها در فصل‌های بعد آمده است.

جمع‌بندی

• تمرکززدایی خدمت اصلی بلاک‌چین است؛ مفهومی قدیمی که با بلاک‌چین اهمیت تازه یافته است.
• دو روش اصلی: حذف واسطه و رقابت میان ارائه‌دهندگان؛ همراه با معیارهایی برای تصمیم میان بلاک‌چین (عمومی/خصوصی) و پایگاه داده سنتی، و چارچوب چهارپرسشی Narayanan.
• تمرکززدایی واقعی مستلزم غیرمتمرکزشدن لایه‌های پیرامونی (ذخیره، ارتباطات، محاسبه، هویت) است و هر کاری به تمرکززدایی نیاز ندارد.
• مفاهیم DO، DAO، DAC، DAS و DApp و حادثهٔ The DAO نشان می‌دهند که این الگو هم فرصت بزرگ دارد و هم ریسک امنیتی و حقوقی.
• فصل بعد به رمزنگاری می‌پردازد که بنیاد فناوری بلاک‌چین است.

فصل ۳ — رمزنگاری متقارن (Symmetric Cryptography)

مقدمه

این فصل مفاهیم، نظریه و جنبهٔ عملی رمزنگاری متقارن (Symmetric Cryptography) را معرفی می‌کند، با تمرکز بر آنچه به بلاک‌چین مربوط است و برای فهم فصل‌های بعد لازم است. برای تجربهٔ عملی از ابزار خط فرمان OpenSSL استفاده می‌شود. ساختار فصل: مبانی ریاضی، مفاهیم و سرویس‌های رمزنگاری، اولیه‌های رمزنگاری (primitives)، رمزهای دنباله‌ای و بلوکی، حالت‌های عملکرد رمز بلوکی، DES و AES و در پایان آزمایش‌های OpenSSL.

کار با خط فرمان OpenSSL

• در Ubuntu معمولاً OpenSSL از قبل نصب است؛ در غیر این صورت با sudo apt-get install openssl.
• مثال‌های فصل با نسخهٔ OpenSSL 1.0.2g (ماه مارس ۲۰۱۶، بستهٔ Ubuntu Xenial) نوشته و آزموده شده‌اند. نسخهٔ خود را با openssl version ببینید. نسخه‌های دیگر ممکن است کار کنند، اما تضمینی نیست؛ چون نسخه‌های قدیمی‌تر برخی قابلیت‌ها را ندارند و نسخه‌های جدیدتر لزوماً سازگار با عقب نیستند.

مقدمهٔ رمزنگاری

• رمزنگاری (Cryptography) علم امن‌سازی اطلاعات در حضور دشمن است، با این فرض که دشمن منابع نامحدود دارد. رمز (cipher) الگوریتمی برای رمزگذاری و رمزگشایی است تا داده در صورت شنود برای دشمن بی‌معنا بماند و بدون کلید محرمانه قابل بازیابی نباشد.
• کاربرد اصلی آن سرویس محرمانگی است، اما به‌تنهایی راه‌حل کامل نیست و یک بلوک ساختمانی در یک سیستم امنیتی گسترده‌تر است. امن‌سازی اکوسیستم بلاک‌چین به اولیه‌های متعدد نیاز دارد: توابع هش، رمزنگاری کلید متقارن، امضای دیجیتال و رمزنگاری کلید عمومی.
• سرویس‌های دیگر: یکپارچگی، احراز هویت (هویت موجودیت و مبدأ داده)، انکارناپذیری و پاسخ‌گویی (accountability).

مبانی ریاضی

بحث کامل با اثبات نیازمند ریاضیات پیشرفته است؛ منبع پیشنهادی: A Course in Number Theory and Cryptography از Neal Koblitz. تعریف‌های پایه:

مفاهیم رمزنگاری

مدل عمومی رمزگذاری/رمزگشایی چهار جزء دارد: متن ساده (P, plaintext)، رمزگذاری (E)، متن رمزشده (C, ciphertext) و رمزگشایی (D). اصطلاحات پایه:

• موجودیت (Entity): شخص یا سیستمی که داده می‌فرستد، می‌گیرد یا روی آن عمل می‌کند.
• فرستنده و گیرنده؛ دشمن (Adversary): موجودیتی که می‌خواهد سرویس امنیتی را دور بزند.
• کلید: داده‌ای برای رمزگذاری یا رمزگشایی دادهٔ دیگر؛ کانال: واسطهٔ ارتباط بین موجودیت‌ها.

سرویس‌های امنیتی

• محرمانگی (Confidentiality): اطمینان از اینکه اطلاعات فقط در دسترس موجودیت‌های مجاز است.
• یکپارچگی (Integrity): اطمینان از اینکه اطلاعات فقط توسط موجودیت‌های مجاز قابل تغییر است.
• احراز هویت (Authentication): اطمینان از هویت موجودیت یا اعتبار پیام؛ دو نوع دارد.

احراز هویت موجودیت (Entity authentication): اطمینان از اینکه موجودیت اکنون در نشست ارتباطی فعال و حاضر است. نام‌کاربری و گذرواژه تنها یک عامل (چیزی که می‌دانید) است و به‌دلیل مشکلاتی مثل نشت گذرواژه ضعیف تلقی می‌شود؛ پس از عامل‌های بیشتر (احراز هویت چندعاملی؛ دوعاملی وقتی دو روش باشد) استفاده می‌شود:

• چیزی که دارید (something you have): توکن سخت‌افزاری یا کارت هوشمند. اگر توکن گم شود بدون گذرواژه بی‌فایده است.
• چیزی که هستید (something you are): ویژگی‌های زیست‌سنجی مثل اثر انگشت، شبکیه، عنبیه یا هندسهٔ دست. پیاده‌سازی باید دقیق باشد، چون برخی پژوهش‌ها نشان داده‌اند در شرایطی می‌توان سامانه‌های زیست‌سنجی را دور زد.

احراز هویت مبدأ داده (Data origin authentication یا message authentication): اطمینان از تأیید منبع اطلاعات؛ چون منبع تأیید شده، یکپارچگی داده هم تضمین می‌شود. روش‌های رایج: کد احراز پیام (MAC) و امضای دیجیتال.

• انکارناپذیری (Non-repudiation): اطمینان از اینکه موجودیت نمی‌تواند تعهد یا عمل قبلی خود را با ارائهٔ شواهد انکارناپذیر انکار کند (مثلاً ثبت سفارش در فروشگاه آنلاین). این سرویس شواهد رمزنگاری‌شده برای حل اختلاف فراهم می‌کند. پروتکل‌های انکارناپذیری در شبکه برای اثبات اقدام مبدأ یا گیرنده به کار می‌روند و دو مدل ارسال دارند: ارسال مستقیم از A به B یا ارسال از طریق یک عامل تحویل. نیازهای اصلی: عدالت (fairness)، اثربخشی (effectiveness) و به‌موقع‌بودن (timeliness). در سناریوهای چندطرفه (مثل معاملات الکترونیکی با کارگزار و اتاق پایاپای) پروتکل‌های دوطرفه کافی نیستند و پروتکل‌های MPNR (چندطرفه) ساخته شده‌اند.
• پاسخ‌گویی (Accountability): امکان ردیابی اقدامات مؤثر بر امنیت تا مسئول آن، معمولاً با ثبت لاگ و ممیزی (مثلاً لاگ معامله با تاریخ، زمان و هویت؛ می‌تواند رمز شود و در پایگاه داده یا فایل متنی جدا باشد).

اولیه‌های رمزنگاری

اولیه‌های رمزنگاری (Cryptographic primitives) بلوک‌های سازندهٔ پروتکل‌ها و سیستم‌های امنیتی‌اند. پروتکل امنیتی مجموعه‌ای از گام‌هاست که با سازوکارهای مناسب به اهداف امنیتی می‌رسد (مثل پروتکل‌های احراز هویت، انکارناپذیری، مدیریت کلید). رمزنگاری در طبقه‌بندی کلی دو شاخه دارد: متقارن و نامتقارن.

رمزنگاری متقارن

در رمزنگاری متقارن کلید رمزگذاری با کلید رمزگشایی یکی است؛ به همین دلیل «رمزنگاری کلید مشترک» یا «کلید محرمانه» هم نامیده می‌شود. کلید باید پیش از تبادل داده بین طرفین ایجاد یا توافق شود. دو نوع رمز متقارن وجود دارد: دنباله‌ای (stream) و بلوکی (block). نمونه‌های بلوکی: DES و AES؛ نمونه‌های دنباله‌ای: RC4 و A5.

رمزهای دنباله‌ای (Stream ciphers)

• بیت‌به‌بیت روی متن ساده و با یک جریان کلید (keystream) رمز می‌کنند.
• همگام (synchronous): جریان کلید فقط به کلید وابسته است. ناهمگام (asynchronous): جریان کلید به داده رمزشده هم وابسته است.
• رمزگذاری و رمزگشایی یک تابع‌اند (جمع پیمانهٔ ۲ یعنی XOR). نیاز بنیادین، امنیت و تصادفی‌بودن جریان کلید است و مولدهای کلید باید از نظر رمزنگاری امن باشند (از مولد اعداد شبه‌تصادفی تا مولد اعداد تصادفی واقعی سخت‌افزاری).

رمزهای بلوکی (Block ciphers)

• متن ساده را به بلوک‌های با طول ثابت می‌شکنند و بلوک‌به‌بلوک رمز می‌کنند.
• بیشتر بر پایهٔ ساختار Feistel (ابداع Horst Feistel) طراحی می‌شوند؛ رمزهای جدید مثل AES (Rijndael) از ترکیب جانشینی و جایگشت یا شبکهٔ SPN (Substitution-Permutation Network) ساخته شده‌اند.
• شبکهٔ Feistel داده را به دو نیمهٔ چپ و راست تقسیم و در چند دور با توابع دوری کلیددار پردازش می‌کند تا جایگشت شبه‌تصادفی حاصل شود. مزیت: رمزگذاری و رمزگشایی تقریباً یکسان‌اند و رمزگشایی فقط معکوس کردن ترتیب است. DES نمونهٔ شاخص آن است.
• دو ویژگی مطلوب: اغتشاش (Confusion) که رابطهٔ متن رمز و متن ساده را پیچیده می‌کند و با جانشینی (در الگوریتم‌های مدرن با جدول‌های جست‌وجو به نام S-box) به دست می‌آید؛ و پخش (Diffusion) که آماره‌های متن ساده را روی خروجی پخش می‌کند، به‌طوری که تغییر یک بیت ورودی به‌طور میانگین دست‌کم نیمی از بیت‌های متن رمز را عوض کند (با جایگشت). این دو یافتن کلید را حتی با دسترسی به جفت‌های متعدد رمز/ساده بسیار سخت می‌کنند.

حالت‌های عملکرد رمز بلوکی

چهار حالت متداول: ECB، CBC، OFB و CTR (حالت‌های دیگر: CFB و GCM). کتاب چند «حالت» را از دید کاربرد دسته‌بندی می‌کند.

حالت رمزگذاری بلوکی (block encryption mode): متن ساده به بلوک‌های ثابت تقسیم و تابع رمزگذاری روی هر بلوک اعمال می‌شود.

حالت تولید جریان کلید (keystream generation mode): تابع رمزگذاری جریان کلید تولید می‌کند و با جریان متن ساده XOR می‌شود.

حالت احراز پیام (message authentication mode): خروجی تابع رمز یک MAC است، یعنی چک‌سام رمزنگاری‌شده برای سرویس یکپارچگی. رایج‌ترین روش با رمز بلوکی CBC-MAC است که بخشی از آخرین بلوک زنجیره به‌عنوان MAC به کار می‌رود. گیرنده پیام دریافتی را دوباره با کلید MAC می‌کند و با MAC فرستنده مقایسه می‌کند؛ تطابق یعنی پیام دست‌نخورده، عدم تطابق یعنی تغییر توسط فرد غیرمجاز.

حالت هش رمزنگاری (cryptographic hash mode): رمز بلوکی به‌عنوان تابع فشرده‌ساز برای تولید هش از متن ساده به کار می‌رود (توابع هش پیام را به خلاصهٔ طول ثابت فشرده می‌کنند).

استاندارد رمزگذاری داده (DES)

• DES را مؤسسهٔ NIST آمریکا به‌عنوان الگوریتم استاندارد معرفی کرد و در دهه‌های ۱۹۸۰ و ۱۹۹۰ پرکاربرد بود. اما به‌دلیل پیشرفت فناوری و پژوهش، در برابر حملهٔ جست‌وجوی فراگیر (brute force) مقاوم نماند: در ژوئیهٔ ۱۹۹۸ بنیاد EFF با دستگاه ویژهٔ EFF DES cracker (Deep Crack) آن را شکست.
• کلید DES فقط ۵۶ بیت است. Triple DES (3DES) با سه کلید ۵۶ بیتی و سه بار اجرای DES کلید مؤثر ۱۶۸ بیتی داد و حملهٔ brute force را تقریباً ناممکن کرد، اما کندی و اندازهٔ بلوک ۶۴ بیتی مطلوب نبود.

استاندارد رمزگذاری پیشرفته (AES)

• در سال ۲۰۰۱ پس از یک رقابت باز، الگوریتم Rijndael از Joan Daemen و Vincent Rijmen با تغییرات اندک توسط NIST به‌عنوان AES استاندارد شد. تا زمان کتاب حمله‌ای مؤثرتر از brute force علیه آن یافت نشده بود.
• Rijndael اصلی اندازهٔ بلوک و کلید ۱۲۸، ۱۹۲ و ۲۵۶ بیت را اجازه می‌داد؛ اما در استاندارد AES بلوک فقط ۱۲۸ بیت است و کلید می‌تواند ۱۲۸، ۱۹۲ یا ۲۵۶ بیت باشد.

نحوهٔ کار AES

آرایهٔ بایتی ۴×۴ به نام state طی چند دور تغییر می‌کند. تعداد دورها به اندازهٔ کلید بستگی دارد:

هر دور چهار مرحله دارد:

1. AddRoundKey: state با زیرکلیدی مشتق‌شده از کلید اصلی XOR می‌شود.
2. SubBytes: جانشینی؛ همهٔ بایت‌های state با جدول S-box عوض می‌شوند.
3. ShiftRows: هر سطر (به‌جز سطر اول) به‌صورت دوری و افزایشی به چپ شیفت می‌یابد.
4. MixColumns: بایت‌ها ستون‌به‌ستون به‌صورت خطی مخلوط می‌شوند.

در دور آخر (دهم، دوازدهم یا چهاردهم) مرحلهٔ چهارم حذف و با AddRoundKey جایگزین می‌شود تا سه مرحلهٔ اول به‌سادگی قابل معکوس‌کردن نباشند. کیف پول‌های ارز رمزنگاری‌شده برای رمزکردن داده‌های ذخیره‌شدهٔ محلی از AES بهره می‌برند؛ مثلاً کیف پول بیت‌کوین از AES-256 در حالت CBC استفاده می‌کند.

آزمایش‌های عملی با OpenSSL

کتاب چند آزمایش با فایل message.txt (۱۴ بایت، حاوی عبارتی مثل «Datatoencrypt») نشان می‌دهد:

• رمزگذاری AES: دستور openssl enc -aes-256-cbc -in message.txt -out message.bin گذرواژه می‌خواهد (و تأیید دوباره) و فایل باینری رمزشده می‌سازد. اندازهٔ خروجی ۳۲ بایت است (۱۶ بایت بلوک padding‌شده + ۱۶ بایت سربرگ salt)، و cat آن بایت‌های ناخوانا نشان می‌دهد.
• کدگذاری Base64: برای سازگاری و انتقال متنی، openssl enc -base64 -in message.bin -out message.b64 فایل ۴۵ بایتی متنی می‌سازد که با پیشوند U2FsdGVkX1… شروع می‌شود (نشانهٔ «Salted__» در ابتدای فایل).
• رمزگشایی: openssl enc -d -aes-256-cbc -in message.bin -out message.dec با گذرواژهٔ درست متن اصلی را بازمی‌گرداند.
• نکتهٔ IV: در دستورها IV داده نشد؛ چون OpenSSL آن را خودکار از گذرواژه می‌سازد (و کلید هم از گذرواژه مشتق می‌شود). کاربر می‌تواند با گزینه‌های -K (کلید) و -iv مقدار هگز مشخص کند.
• رمزگشایی Base64: با openssl enc -d -base64 -in message.b64 -out message.ptx فایل باینری اصلی بازیابی می‌شود.
• OpenSSL رمزهای متنوع دیگری هم پشتیبانی می‌کند (فهرست در تصویر کتاب) و می‌توان همین الگو را با آن‌ها تمرین کرد.

جمع‌بندی

• رمزنگاری علم امن‌سازی اطلاعات در برابر دشمن است و سرویس‌های محرمانگی، یکپارچگی، احراز هویت، انکارناپذیری و پاسخ‌گویی را فراهم می‌کند؛ ابزارش اولیه‌های رمزنگاری‌اند، نه راه‌حل منفرد.
• رمزنگاری متقارن از یک کلید مشترک برای رمزگذاری و رمزگشایی بهره می‌برد و دو خانواده دارد: دنباله‌ای (XOR با جریان کلید) و بلوکی (Feistel یا SPN با ویژگی‌های اغتشاش و پخش).
• حالت‌های عملکرد (ECB ناامن، CBC با IV، CTR با nonce و شمارنده، به‌علاوهٔ حالت‌های MAC و هش) تعیین می‌کنند رمز بلوکی چگونه روی داده‌های طولانی اعمال شود.
• DES با کلید ۵۶ بیتی شکسته شد؛ 3DES آن را موقتاً تقویت کرد؛ AES (۱۰/۱۲/۱۴ دور برای کلید ۱۲۸/۱۹۲/۲۵۶) استاندارد غالب امروز است و در کیف پول‌ها به‌کار می‌رود.
• فصل بعد رمزنگاری کلید عمومی را معرفی می‌کند که در بلاک‌چین بسیار پرکاربرد است.

فصل ۴ — رمزنگاری کلید عمومی (Public Key Cryptography)

مقدمه

این فصل ادامهٔ فصل قبل (رمزنگاری متقارن) است و مفاهیم نظری و عملی رمزنگاری کلید عمومی (Public Key Cryptography) را که رمزنگاری نامتقارن (Asymmetric Cryptography) هم نامیده می‌شود، معرفی می‌کند. مسیر فصل چنین است:

• مبانی نظری رمزنگاری نامتقارن و سه خانوادهٔ ریاضی پشت آن؛
• دو نمونهٔ مهم: RSA و رمزنگاری منحنی بیضوی (ECC)، همراه با آزمایش‌های عملی با OpenSSL؛
• توابع هش (Hash functions)، ویژگی‌های امنیتی، خانواده‌های مختلف و طراحی SHA-256 و SHA-3؛
• MAC و HMAC، و سپس کاربردهای هش در ساختارهایی مانند درخت مرکل، درخت پاتریشیا و جدول هش توزیع‌شده؛
• امضای دیجیتال با RSA و ECDSA و نمونه‌های OpenSSL؛
• مفاهیم پیشرفته‌تر: رمزنگاری همومورفیک، signcryption، اثبات دانش صفر، امضای کور و طرح‌های کدگذاری؛
• در پایان، بخشی مقدماتی دربارهٔ بازارهای مالی و معاملات (که زمینهٔ کاربردهای مالی بلاک‌چین در فصل‌های بعد است).

رمزنگاری نامتقارن

در رمزنگاری نامتقارن، کلیدی که داده را رمز می‌کند با کلیدی که آن را رمزگشایی می‌کند متفاوت است. هر کاربر یک کلید عمومی و یک کلید خصوصی دارد. طرح‌های رایج: RSA، DSA و ElGamal.

دو الگوی کاربرد

1. رمزنگاری/رمزگشایی: فرستنده متن ساده P را با کلید عمومی گیرنده و تابع رمز E به متن رمزشدهٔ C تبدیل می‌کند؛ گیرنده با کلید خصوصی خود و تابع D دوباره P را می‌گیرد. مزیت مهم این است که نیازی به تبادل کلید مخفی بین طرفین نیست (برخلاف رمزنگاری متقارن).
2. امضا/اعتبارسنجی: فرستنده پیام را با کلید خصوصی خود و تابع امضا S امضا می‌کند و گیرنده با کلید عمومی فرستنده و تابع تأیید V اصالت پیام را می‌سنجد. در این الگو لزوماً رمزنگاری انجام نمی‌شود؛ هدف صرفاً احراز اصالت و یکپارچگی است.

سازوکارهای امنیتی قابل ارائه

• برقراری کلید (key establishment): طراحی پروتکل‌هایی برای توافق بر سر کلید روی کانال ناامن؛
• امضای دیجیتال و در نتیجه عدم انکار (non-repudiation)؛
• شناسایی (identification): ترکیب امضا با پروتکل‌های challenge-response برای تشخیص هویت طرف مقابل؛
• رمزنگاری برای محرمانگی (با RSA، ECC یا ElGamal).

الگوریتم‌های کلید عمومی از نظر محاسباتی کندتر از الگوریتم‌های متقارن‌اند؛ بنابراین معمولاً برای رمز کردن فایل‌های بزرگ استفاده نمی‌شوند، بلکه برای تبادل کلید به کار می‌روند و پس از برقراری امن کلید، رمزنگاری دادهٔ اصلی با الگوریتم متقارن انجام می‌شود.

سه دستهٔ ریاضی

مثال کتاب برای لگاریتم گسسته: از 3² mod 10 = 9 به‌سادگی حاصل ۹ به دست می‌آید، اما با داشتن فقط ۹ پیدا کردن توان ۲ (روی مولد ۳) در اعداد بزرگ بسیار دشوار است.

منحنی بیضوی منحنی جبری درجه سه روی یک میدان است که نامنفرد (non-singular) است، یعنی نه نقطهٔ بازگشت (cusp) دارد نه خودتقاطعی، و علاوه بر نقاط خود شامل یک «نقطهٔ بی‌نهایت» است. در رمزنگاری، منحنی روی میدان متناهی با پیمانهٔ اول (بزرگ‌تر از ۳) تعریف می‌شود، نه روی اعداد حقیقی؛ با تغییر ضرایب a و b منحنی‌های مختلف به دست می‌آید.

کلیدهای عمومی و خصوصی

• کلید خصوصی: عددی تصادفی که فقط نزد مالک محفوظ است. افشای آن کل طرح را بی‌اعتبار می‌کند. طول آن به الگوریتم بستگی دارد؛ در RSA معمولاً ۱۰۲۴ یا ۲۰۴۸ بیت، با این توضیح که ۱۰۲۴ بیت دیگر امن شمرده نمی‌شود و حداقل ۲۰۴۸ بیت توصیه می‌شود.
• کلید عمومی: آزادانه منتشر می‌شود. هرکس می‌تواند پیامی را با آن برای صاحب کلید رمز کند و فقط دارندهٔ کلید خصوصی متناظر می‌تواند آن را بگشاید.
• نگرانی مهم دربارهٔ کلیدهای عمومی اصالت و هویتِ منتشرکننده است: از کجا بدانیم این کلید واقعاً متعلق به همان شخص است؟ (پاسخ عملی: گواهی‌های دیجیتال و مراجع صدور گواهی.)

RSA

RSA در سال ۱۹۷۷ توسط Ron Rivest، Adi Shamir و Leonard Adleman ابداع شد و مبتنی بر مسئلهٔ تجزیه است: ضرب دو عدد اول بزرگ آسان، اما بازگرداندن حاصل‌ضرب به دو عامل اولیه دشوار است.

تولید کلید (چهار گام)

1. مدول: دو عدد اول بسیار بزرگ p و q انتخاب می‌شود و n = p·q مدول است.
2. عدد هم‌اول: عددی مانند e بزرگ‌تر از ۱ و کوچک‌تر از (p−1)(q−1) انتخاب می‌شود که با (p−1)(q−1) هم‌اول باشد (تنها مقسوم‌علیه مشترک آن‌ها ۱ است).
3. کلید عمومی: زوج (n, e). p و q باید مخفی بمانند.
4. کلید خصوصی d: وارون e به پیمانهٔ (p−1)(q−1)، یعنی ed ≡ 1 (mod (p−1)(q−1))، که معمولاً با الگوریتم اقلیدسی توسعه‌یافته محاسبه می‌شود.

ایدهٔ کلیدی: هر که p و q را بداند به‌آسانی d را می‌سازد، اما کسی که نداند نمی‌تواند؛ پس p و q باید آن‌قدر بزرگ باشند که تجزیهٔ n عملاً غیرممکن شود.

رمز و رمزگشایی

• رمز: C = Pᵉ mod n
• رمزگشایی: P = Cᵈ mod n

رمزنگاری منحنی بیضوی (ECC)

ECC بر مسئلهٔ لگاریتم گسسته روی منحنی‌های بیضوی در میدان‌های متناهی (میدان‌های گالوا) استوار است. مزیت اصلی آن نسبت به الگوریتم‌هایی مانند RSA این است که برای همان سطح امنیت به کلید کوچک‌تری نیاز دارد؛ مثلاً امنیتی که RSA با ۳۰۷۲ بیت دارد، با عملوندهای ۲۵۶ بیتی در ECC حاصل می‌شود. به همین دلیل در پلتفرم‌های نهفته و سامانه‌هایی با فضای ذخیرهٔ محدود محبوب است. دو طرح مشتق‌شده مهم: ECDH (تبادل کلید) و ECDSA (امضای دیجیتال). ECC برای رمزنگاری مستقیم هم قابل استفاده است اما در عمل معمولاً به این منظور به کار نمی‌رود.

ریاضیات ECC

منحنی بیضوی نوعی معادلهٔ چندجمله‌ای به شکل معادلهٔ وایرشتراس (Weierstrass) است (y² = x³ + Ax + B). در رمزنگاری، ضرایب A و B عضو میدان اول متناهی Zp (یا Fp) هستند و علاوه بر نقاط منحنی یک نقطهٔ بی‌نهایت وجود دارد که نقش عنصر خنثی (identity) را برای عمل گروه بازی می‌کند. شرط نامنفرد بودن (نداشتن ریشهٔ تکراری) باید برقرار باشد؛ در عمل 4A³ + 27B² ≠ 0 (mod p).

برای ساخت مسئلهٔ لگاریتم گسسته به یک گروه دوری (cyclic group) به‌اندازهٔ کافی بزرگ نیاز است: عناصر گروه مجموعه نقاط روی منحنی‌اند و دو عمل گروه تعریف می‌شود.

جمع نقاط (Point addition)

دو نقطهٔ متمایز P و Q با هم جمع می‌شوند. از نظر هندسی خطی از P و Q رسم می‌شود؛ این خط منحنی را در نقطهٔ سومی قطع می‌کند و قرینهٔ آن نقطه نسبت به محور x برابر R = P + Q است. به‌صورت جبری برای (x₁,y₁) + (x₂,y₂) = (x₃,y₃):

• x₃ = s² − x₁ − x₂ (mod p)
• y₃ = s(x₁ − x₃) − y₁ (mod p)

که s شیب خط گذرنده از P و Q است. کتاب مثالی با ابزار آنلاین Certicom روی میدان F₂₃ ارائه می‌دهد: منحنی روی این میدان ۲۷ جواب (نقطه) دارد و برای نمونه نقطهٔ (3, 6) معادله را برآورده می‌کند؛ سپس دو نقطه جمع شده و نقطهٔ سوم محاسبه می‌شود.

دوبرابر کردن نقطه (Point doubling)

وقتی نقطه با خودش جمع می‌شود (2P = P + P)، به‌جای خط عبوری از دو نقطه، خط مماس بر منحنی در P رسم می‌شود؛ محل تقاطع دوم مماس با منحنی قرینه می‌شود و نتیجه 2P است. در این حالت شیب s همان شیب مماس در P است. کتاب نمونهٔ دوبرابرسازی را هم روی F₂₃ نشان می‌دهد.

مسئلهٔ لگاریتم گسسته در ECC

• کلید خصوصی d عددی صحیح و تصادفی است و کلید عمومی T نقطه‌ای روی منحنی است که مضربی از نقطهٔ مولد (generator) P است: T = d·P.
• مسئله: با داشتن P و T، یافتن d در بازهٔ 1 ≤ d ≤ #E، که #E مرتبهٔ منحنی (تعداد نقاط گروه دوری شامل نقطهٔ بی‌نهایت) است. این کار عملاً شدنی نیست.
• هر زوج کلید به پارامترهای دامنه (domain parameters) یک منحنی خاص گره خورده است: اندازهٔ میدان، نحوهٔ نمایش آن، ضرایب a و b، مختصات نقطهٔ پایه G=(Xg, Yg)، مرتبهٔ n برای G و هم‌عامل (cofactor) h = #E(Fq)/n.

پارامترهای secp256k1

منحنی استاندارد مورد استفاده در بیت‌کوین (و اتریوم) secp256k1 است که در مشخصات SEC 2 تعریف شده است. این پارامترها به‌صورت یک «شش‌تایی» (p, a, b, G, n, h) توصیف می‌شوند:

• p: عدد اولی که اندازهٔ میدان متناهی را تعیین می‌کند؛
• a و b: ضرایب معادلهٔ منحنی (برای secp256k1 مقادیر a = 0 و b = 7)؛
• G: نقطهٔ پایهٔ مولد زیرگروه، که می‌توان آن را فشرده یا غیرفشرده نمایش داد (نقاط منحنی با مختصات x و کم‌ارزش‌ترین بیت y قابل بازیابی‌اند و لازم نیست همهٔ نقاط ذخیره شوند)؛
• n: مرتبهٔ زیرگروه؛
• h: هم‌عامل زیرگروه (برای secp256k1 برابر ۱).

آزمایش RSA با OpenSSL

کتاب چند دستور عملی را به ترتیب نشان می‌دهد (خروجی‌های طولانی PEM و هگز خلاصه نمی‌شوند):

• ساخت کلید خصوصی ۱۰۲۴ بیتی: openssl genpkey -algorithm RSA -out privatekey.pem -pkeyopt rsa_keygen_bits:1024. فایل خروجی PEM با base64 رمزگذاری شده و بین BEGIN PRIVATE KEY و END PRIVATE KEY قرار دارد.
• استخراج کلید عمومی از روی خصوصی: openssl rsa -pubout -in privatekey.pem -out publickey.pem (چون دو کلید از نظر ریاضی به هم مرتبط‌اند).
• بررسی اجزای کلید با openssl rsa -text -in privatekey.pem: مدول، توان عمومی (publicExponent برابر ۶۵۵۳۷ یا 0x10001)، توان خصوصی، و دو عدد اول prime1 و prime2 دیده می‌شود. همچنین openssl pkey -in publickey.pem -pubin -text مدول و توان عمومی کلید عمومی را نشان می‌دهد.
• رمز کردن: فایل message.txt حاوی «datatoencrypt» با openssl rsautl -encrypt -inkey publickey.pem -pubin رمز می‌شود و فایل باینری message.rsa تولید می‌شود که در ویرایشگر متن فقط بی‌معنا دیده می‌شود.
• رمزگشایی: با openssl rsautl -decrypt -inkey privatekey.pem متن اصلی بازیابی و با cat قابل مشاهده است.

آزمایش ECC با OpenSSL

• فهرست منحنی‌ها: openssl ecparam -list_curves منحنی‌های استاندارد را نشان می‌دهد (secp112r1 تا secp521r1، prime192v1، brainpool و …)، از جمله secp256k1.
• ساخت کلید خصوصی روی secp256k1: openssl ecparam -name secp256k1 -genkey -noout -out ec-privatekey.pem.
• استخراج کلید عمومی: openssl ec -in ec-privatekey.pem -pubout -out ec-pubkey.pem.
• بررسی کلیدها با -text -noout: کلید خصوصی ۲۵۶ بیتی (مقدار priv)، کلید عمومی ۶۵ بایتی غیرفشرده با پیشوند 04 (pub) و شناسهٔ ASN1 OID برابر secp256k1.
• بررسی پارامترهای منحنی: با ساخت فایل پارامتر و اجرای openssl ecparam -in secp256k1.pem -text -param_enc explicit -noout مقادیر زیر دیده می‌شود: نوع میدان prime-field، عدد اول p (به شکل ff…fffffc2f)، A = 0 و B = 7، مولد غیرفشرده، مرتبه (order) و cofactor برابر ۱.

توابع هش (Hash functions)

تابع هش ورودی با طول دلخواه را به چکیدهٔ (digest) طول‌ثابت تبدیل می‌کند. توابع هش بدون کلید (keyless) هستند و خدمت یکپارچگی داده را ارائه می‌دهند. خانواده‌های اصلی: MD، SHA-1، SHA-2، SHA-3، RIPEMD و Whirlpool. کاربردها: امضای دیجیتال، کدهای احراز اصالت پیام (MAC/HMAC)، ساخت دیگر ابزارهای رمزنگاری، و حتی تولید اعداد شبه‌تصادفی (PRNG).

ویژگی‌های کاربردی

• فشرده‌سازی ورودی دلخواه به خروجی ثابت (معمولاً ۱۲۸ تا ۵۱۲ بیت)؛
• سهولت محاسبه: حتی برای پیام‌های بزرگ باید سریع باشد.

ویژگی‌های امنیتی

از آنجا که فضای ورودی بی‌نهایت و خروجی محدود است، برخورد همیشه وجود دارد؛ نکته آن است که یافتنش از نظر محاسباتی غیرعملی باشد. ویژگی مطلوب دیگر اثر بهمنی (avalanche effect) است: تغییر کوچک ورودی (حتی یک حرف) خروجی کاملاً متفاوتی می‌دهد.

ساختار طراحی

بیشتر توابع هش به روش تکراری (iterated) ساخته می‌شوند: پیام بلوک‌به‌بلوک و در چند دور فشرده می‌شود. نمونهٔ معروف ساختار Merkle-Damgård است که ورودی را به بلوک‌های هم‌اندازه می‌شکند و از تابع فشرده‌ساز عبور می‌دهد؛ مقاوم‌بودن تابع فشرده‌ساز در برابر برخورد، همین ویژگی را به کل هش منتقل می‌کند. توابع فشرده‌ساز را می‌توان از رمزهای بلوکی ساخت. ساختارهای دیگر: Miyaguchi-Preneel و Davies-Meyer.

خانواده‌های هش

• Message Digest (MD4، MD5): رایج در اوایل دههٔ ۱۹۹۰؛ ناامن شناخته شده‌اند. MD5 هش ۱۲۸ بیتی بود که برای بررسی صحت فایل استفاده می‌شد.
• SHA-0: ۱۶۰ بیت، NIST، ۱۹۹۳.
• SHA-1: ۱۶۰ بیت، ۱۹۹۵، جایگزین SHA-0؛ در SSL/TLS رایج بود ولی اکنون ناامن است و مراجع صدور گواهی آن را کنار می‌گذارند.
• SHA-2: چهار تابع SHA-224، SHA-256، SHA-384 و SHA-512.
• SHA-3: جدیدترین خانواده (SHA-3-224/256/384/512)، نسخهٔ استانداردشدهٔ NIST از Keccak که به‌جای Merkle-Damgård از ساختار اسفنجی (sponge) استفاده می‌کند.
• RIPEMD: بر پایهٔ ایده‌های MD4، نسخه‌های ۱۲۸، ۱۶۰، ۲۵۶ و ۳۲۰ بیتی.
• Whirlpool: بر پایهٔ نسخهٔ اصلاح‌شدهٔ رمز Rijndael (به نام W) و تابع فشرده‌ساز Miyaguchi-Preneel.

کاربردهای عمومی هش: بررسی صحت فایل، ذخیرهٔ گذرواژه، پروتکل‌های رمزنگاری، جدول‌های هش، DHT، فیلتر بلوم، اثرانگشت ویروس، اشتراک فایل همتابه‌همتا. در بلاک‌چین نقش کلیدی دارند: اثبات کار بیت‌کوین SHA-256 را دوبار به کار می‌برد و RIPEMD-160 در تولید آدرس بیت‌کوین استفاده می‌شود.

طراحی SHA-256

• پیام ورودی کوچک‌تر از 2⁶⁴ بیت، اندازهٔ بلوک ۵۱۲ بیت، اندازهٔ کلمه ۳۲ بیت، خروجی ۲۵۶ بیت.
• تابع فشرده‌ساز یک بلوک ۵۱۲ بیتی و یک مقدار هش میانی ۲۵۶ بیتی را پردازش می‌کند و دو بخش دارد: خود تابع فشرده‌ساز و زمان‌بندی پیام (message schedule).
• الگوریتم در دو مرحلهٔ کلی:
  1. پیش‌پردازش: پدینگ (padding) برای رساندن طول به مضرب ۵۱۲ بیت؛ تجزیهٔ پیام به بلوک‌های ۵۱۲ بیتی؛ تعیین مقدار اولیه هش از هشت کلمهٔ ۳۲ بیتی که از ۳۲ بیت نخست بخش کسری ریشهٔ دوم هشت عدد اول نخست به دست می‌آید (این انتخاب «عدد شانسی نیست» و اطمینان می‌دهد درِ پشتی وجود ندارد).
  2. محاسبهٔ هش: هر بلوک در ۶۴ دور پردازش می‌شود، هر دور ثابت‌های متفاوتی دارد؛ زمان‌بندی پیام آماده می‌شود، هشت متغیر کاری (a تا h) مقداردهی می‌شوند، مقدار هش میانی به‌روز می‌شود و در پایان خروجی تولید می‌شود. در هر دور توابع بیتی Maj و Ch، چرخش بیتی، و جمع ثابت‌های Wj و Kj به پیمانهٔ 2³² اعمال می‌شود.

طراحی SHA-3 (Keccak)

ساختار آن با SHA-1/SHA-2 بسیار متفاوت است: بر جایگشت‌های بدون کلید استوار است و از Merkle-Damgård استفاده نمی‌کند. روش «اسفنج و فشردن» (sponge and squeeze) را به کار می‌برد: داده پس از پدینگ «جذب» اسفنج می‌شود (با XOR وارد بخشی از حالت جایگشت می‌گردد) و سپس خروجی از حالت تبدیل‌شده «بیرون فشرده» می‌شود. rate اندازهٔ بلوک ورودی است و capacity سطح امنیت کلی را تعیین می‌کند. گونه‌های استاندارد: SHA-3-224/256/384/512 و SHAKE-128/256 که توابع خروجی توسعه‌پذیر (XOF) اند و طول خروجی دلخواه دارند.

نکتهٔ مهم: اتریوم SHA-3 استاندارد NIST را به کار نمی‌برد، بلکه Keccak اصلی را که به NIST ارائه شده بود. NIST پس از تغییراتی (افزایش تعداد دورها، پدینگ ساده‌تر) آن را استاندارد کرد، و به همین دلیل خروجی‌ها یکسان نیستند. بیت‌کوین SHA-256 و اتریوم Keccak را استفاده می‌کند.

مثال OpenSSL برای هش

دستور echo -n 'Hello' | openssl dgst -sha256 هش ۲۵۶ بیتی را می‌دهد (با شروع 185f8db3…). با تغییر H بزرگ به h کوچک (hello) خروجی (2cf24dba…) کاملاً متفاوت می‌شود؛ نمایش مستقیم اثر بهمنی.

کد احراز اصالت پیام (MAC)

MAC یا «تابع هش کلیددار» یکپارچگی و احراز اصالت منبع داده را فراهم می‌کند. این‌ها ابزارهای متقارن‌اند و فرستنده و گیرنده کلید مشترک دارند. دو روش ساخت:

• از رمز بلوکی: رمز بلوکی (مثلاً AES) در حالت CBC به کار می‌رود و MAC خروجی آخرین دور CBC است؛ طول MAC برابر اندازهٔ بلوک رمز است. گیرنده MAC را دوباره محاسبه و مقایسه می‌کند؛ تطابق یعنی پیام دست‌نخورده است.
• از تابع هش (HMAC): کلید با پیام ترکیب و هش می‌شود. دو روش ساده: پیشوند مخفی h(k‖x) و پسوند مخفی h(x‖k)؛ هر دو حملاتی دارند، و ساختارهای HMAC با پد داخلی و خارجی (ipad و opad) پیشنهاد شده‌اند که با فرض‌هایی امن‌اند.

MAC مانند امضای دیجیتال کار می‌کند اما به دلیل ماهیت متقارنش عدم انکار را تأمین نمی‌کند.

کاربردهای هش در ساختارهای داده

درخت مرکل (Merkle tree)

ایدهٔ Ralph Merkle. درخت دودویی که ورودی‌ها در برگ‌ها قرار می‌گیرند و هش جفت‌فرزندان برای ساخت گره والد به‌طور تکراری محاسبه می‌شود تا یک هش واحد به نام ریشهٔ مرکل (Merkle root) باقی بماند. تأیید ایمن و کارای مجموعه‌داده‌های بزرگ را ممکن می‌کند و هستهٔ بلاک‌چین‌هاست.

درخت پاتریشیا (Patricia tree)

ابتدا trie (درخت دیجیتال): ساختار درختی مرتب برای ذخیرهٔ یک مجموعه‌داده. Patricia (Practical Algorithm to Retrieve Information Coded in Alphanumeric) یا درخت Radix نمایشی فشرده از trie است که در آن گرهٔ تک‌فرزند با والدش ادغام می‌شود. درخت مرکل-پاتریشیا درختی است که گره ریشهٔ آن هش کل ساختار داده را در بر دارد (در اتریوم کاربرد دارد).

جدول هش توزیع‌شده (DHT)

جدول هش کلیدها را با تابع هش به اندیس آرایه‌ای از «سطل‌ها» (buckets) نگاشت می‌کند. در DHT داده روی گره‌های مختلف یک شبکهٔ همتابه‌همتا پخش است و گره‌ها نقش سطل را دارند. داده از تابع هش می‌گذرد، کلید فشرده تولید می‌شود و با داده در شبکه پیوند می‌خورد؛ هنگام درخواست، نام فایل دوباره هش می‌شود و هر گره می‌تواند داده را بیابد. DHT تمرکززدایی، تحمل خطا و مقیاس‌پذیری می‌دهد.

امضاهای دیجیتال

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

الگوریتم امضای RSA (دو مرحله)

1. محاسبهٔ هش داده (برای تضمین یکپارچگی؛ امضای مستقیم بدون هش ممکن است ولی ناامن تلقی می‌شود)؛
2. امضای مقدار هش با کلید خصوصی امضاکننده.

ویژگی‌های مهم امضا: اصالت (authenticity، قابل راستی‌آزمایی توسط گیرنده)، جعل‌ناپذیری (unforgeability، فقط دارندهٔ کلید خصوصی می‌تواند امضا کند) و غیرقابل‌استفادهٔ مجدد (nonreusability، امضا را نمی‌شود جدا و روی پیام دیگری به کار برد).

ترکیب امضا و رمز

• امضا سپس رمز (sign then encrypt): داده امضا می‌شود، امضا به آن افزوده می‌شود و مجموعه با کلید عمومی گیرنده رمز می‌شود؛ امن‌تر از روش بعدی شمرده می‌شود.
• رمز سپس امضا (encrypt then sign): ابتدا داده با کلید عمومی گیرنده رمز و سپس دادهٔ رمزشده امضا می‌شود.

در عمل گواهی دیجیتال حاوی امضا را یک مرجع صدور گواهی (CA) صادر می‌کند و کلید عمومی را به هویت پیوند می‌دهد.

RSA، DSA و ECDSA

RSA رایج‌ترین است، اما با رشد ECC، طرح‌های مبتنی بر ECDSA هم محبوب‌اند. در بلاک‌چین ECC مفیدتر است چون همان امنیت را با فضای کمتر می‌دهد و تولید کلید در آن بسیار سریع‌تر از RSA است. جدول معادل بودن اندازهٔ کلید برای یک سطح امنیت یکسان:

الگوریتم ECDSA

تولید کلید:

1. منحنی E با مدول p و ضرایب a, b و نقطهٔ مولد A که گروه دوری با مرتبهٔ اول q می‌سازد تعریف می‌شود.
2. عدد صحیح تصادفی d با 0 < d < q انتخاب می‌شود (کلید خصوصی Kpr = d).
3. کلید عمومی B = d·A محاسبه می‌شود؛ کلید عمومی شش‌تایی Kpb = (p, a, b, q, A, B).

تولید امضا:
4. کلید موقت (ephemeral) Ke با 0 < Ke < q انتخاب می‌شود. این مقدار حتماً باید واقعاً تصادفی باشد و برای هر امضا تکرار نشود، وگرنه کلید خصوصی قابل محاسبه است.
5. R = Ke·A محاسبه و r برابر مختصات x نقطهٔ R قرار داده می‌شود.
6. مقدار s از ترکیب هش پیام h(m)، کلید خصوصی d، r و Ke (به پیمانهٔ q) محاسبه می‌شود؛ امضا زوج (r, s) است.

تأیید امضا:

1. w = s⁻¹ mod q
2. u₁ = w·h(m) mod q
3. u₂ = w·r mod q
4. نقطهٔ P = u₁·A + u₂·B محاسبه می‌شود.
5. اگر مختصات x نقطهٔ P با r (mod q) برابر باشد امضا معتبر و در غیر این صورت نامعتبر است.

نمونه‌های OpenSSL برای امضا

• RSA: openssl dgst -sha256 message.txt هش فایل را می‌دهد؛ با openssl dgst -sha256 -sign privatekey.pem -out signature.bin message.txt هش و امضا در یک گام انجام می‌شود (امضای ۱۲۸ بایتی برای کلید ۱۰۲۴ بیتی). تأیید با -verify publickey.pem -signature signature.bin message.txt پیام «Verified OK» می‌دهد؛ با امضای نامعتبر دیگری، «Verification Failure».
• ECDSA: کلید خصوصی secp256k1 ساخته و کلید عمومی از آن استخراج می‌شود؛ فایل testsign.txt با openssl dgst -ecdsa-with-SHA1 -sign eccprivatekey.pem امضا و با -verify eccpublickey.pem تأیید می‌شود (Verified OK).
• گواهی X.509: با openssl req -new -key eccprivatekey.pem -x509 -nodes -days 365 گواهی خودامضا برای ۳۶۵ روز ساخته می‌شود و پرسش‌های نام متمایز (DN) مانند کشور، سازمان و Common Name پر می‌شود؛ سپس با openssl x509 -in ecccertificate.pem -text -noout محتوای آن (الگوریتم ECDSA با SHA-256) بررسی می‌شود.

مفاهیم پیشرفتهٔ رمزنگاری مرتبط با بلاک‌چین

رمزنگاری همومورفیک (Homomorphic encryption)

سامانه‌های کلید عمومی مانند RSA ضربی-همومورفیک‌اند و طرح‌هایی مانند Paillier جمعی-همومورفیک؛ این‌ها همومورفیک جزئی (PHE) نام دارند. جمعی‌ها برای رأی‌گیری الکترونیکی و کاربردهای بانکی مناسب‌اند. در سال ۲۰۰۹ Craig Gentry اولین طرح همومورفیک کامل (FHE) را معرفی کرد که هر دو عمل را پشتیبانی می‌کند و امکان پردازش دادهٔ رمزشده بدون رمزگشایی را می‌دهد؛ مفید برای رایانش ابری و موتورهای جستجو. این فناوری برای حل مشکل محرمانگی و حریم خصوصی در بلاک‌چین جالب است، هرچند هنوز در حال بهبود کارایی است.

Signcryption

Signcryption که Yuliang Zheng ابداع کرد و استاندارد ISO/IEC 29150:2011 است، همهٔ خدمات امضا و رمزنگاری را در یک گام منطقی می‌دهد، با هزینه‌ای بسیار کمتر از مجموع هزینه‌های امضا و رمز جداگانه (و حتی کمتر از sign-then-encrypt).

اثبات‌های دانش صفر (Zero-Knowledge Proofs)

ZKP را Goldwasser، Micali و Rackoff در ۱۹۸۵ معرفی کردند: اثبات درستی یک ادعا بدون افشای هیچ اطلاعاتی دربارهٔ آن. سه ویژگی لازم:

• کامل بودن (completeness): اگر ادعا درست باشد، اثبات‌کننده راستگو، بازبین را متقاعد می‌کند؛
• درستی/استواری (soundness): اگر ادعا نادرست باشد، هیچ اثبات‌کنندهٔ متقلبی نمی‌تواند بازبین را قانع کند؛
• دانش صفر (zero-knowledge): جز درست یا نادرست بودن ادعا چیزی فاش نمی‌شود.

برای حریم خصوصی در حوزه‌های مالی، حقوقی و پزشکی جذاب است. نمونهٔ موفق: ارز Zcash که از ZK-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) بهره می‌برد؛ در فصل ۸ بررسی می‌شود.

امضاهای کور (Blind signatures)

David Chaum در ۱۹۸۲ مطرح کرد. بر پایهٔ امضاهای کلید عمومی مانند RSA است؛ پیام پیش از امضا «کور» (پنهان) می‌شود تا امضاکننده بدون دیدن محتوا آن را امضا کند، و امضای حاصل مانند امضای معمولی در برابر پیام اصلی قابل تأیید است. انگیزه: ساخت پول دیجیتال (digital cash).

طرح‌های کدگذاری (Encoding schemes)

برای تبدیل داده‌های باینری به متن جهت پردازش، ذخیره یا انتقال از پروتکل‌هایی که باینری را نمی‌پذیرند. مثلاً ذخیرهٔ تصویر به‌صورت base64 در یک فیلد متنی پایگاه داده. base64 رایج‌ترین است و base58 با بیت‌کوین مشهور شد.

بازارهای مالی و معاملات (زمینهٔ کاربردهای مالی)

کتاب برای فصل‌های بعدی اصطلاحات پایهٔ بازارهای مالی را معرفی می‌کند.

انواع بازار

• بازار پول (Money markets): وام‌دهی کوتاه‌مدت به شرکت‌ها یا بانک‌ها (بین‌بانکی)؛ بازار ارز (FX) هم در این دسته است.
• بازار اعتبار (Credit markets): عمدتاً بانک‌های خرد که از بانک مرکزی قرض می‌گیرند و به شرکت‌ها و خانوارها وام یا وام مسکن می‌دهند.
• بازار سرمایه (Capital markets): خرید و فروش ابزارهای مالی، به‌ویژه سهام و اوراق قرضه؛ بازار اولیه (انتشار مستقیم توسط شرکت به سرمایه‌گذار) و بازار ثانویه (فروش مجدد از طریق بورس).

معامله

معامله فعالیتی برای کسب سود و پوشش ریسک است؛ فعالان: سرمایه‌گذار، قرض‌گیرنده، هج‌کننده، مبادله‌کنندهٔ دارایی و قمارباز. موقعیت کوتاه (short) یعنی فروش قرارداد و موقعیت بلند (long) یعنی خرید آن. معاملات از طریق کارگزار (broker، که به نمایندگی از مشتری به قیمت مشخص یا بهترین قیمت ممکن معامله می‌کند)، مستقیماً در بورس، یا خارج از بورس (OTC) انجام می‌شود.

بورس‌ها

بورس‌ها مکانی ایمن، تنظیم‌شده و قابل‌اعتماد شمرده می‌شوند. در دههٔ اخیر معاملات الکترونیکی بر معاملات سنتی در سالن بورس غلبه یافته است: سفارش‌ها به یک دفتر سفارش مرکزی الکترونیکی می‌رسند و قیمت‌ها و ویژگی‌ها برای همهٔ سامانه‌ها منتشر می‌شود. فقط اعضای بورس می‌توانند در آن معامله کنند؛ معامله بدون این محدودیت از راه OTC ممکن است.

سفارش‌ها

ویژگی‌های سفارش: نام ابزار، مقدار، جهت (خرید/فروش)، و نوع. قیمتی که خریدار می‌پذیرد bid و قیمتی که فروشنده می‌پذیرد offer نام دارد. سامانه‌های مدیریت و مسیریابی سفارش (OMS) سفارش را از مشتری به کارگزار، سپس به دلال، اتاق پایاپای و بورس می‌رسانند. دو نوع رایج:

• سفارش بازار (market order): معامله فوری به بهترین قیمت لحظه‌ای؛
• سفارش حدی (limit order): معامله فقط در قیمت تعیین‌شده یا بهتر (مثلاً فروش سهام مایکروسافت در ۱۰۰ دلار یا بیشتر). stop order هم به رسیدن قیمت مشخص وابسته است.

سفارش‌ها در دفتر سفارش (order book) که بورس نگه می‌دارد ثبت می‌شوند. موقعیت (position) تعهد به خرید یا فروش مقداری از ابزار مالی به قیمت معین است. ابزارها تحت کلاس‌های دارایی قرار می‌گیرند: دارایی واقعی، مالی، قراردادهای مشتقه و بیمه.

اجزای یک معامله (Trade ticket)

• ابزار پایه (underlying): ارز، اوراق قرضه، نرخ بهره، کالا یا سهام؛
• ویژگی‌های عمومی: شناسهٔ یکتا، نام ابزار، نوع، وضعیت، تاریخ و ساعت معامله؛
• اقتصادی (economics): ارزش خرید/فروش، نماد (ticker)، بورس، قیمت و مقدار؛
• فروش (sales): اطلاعات اطلاعاتی مانند نام فروشنده، بدون اثر بر چرخهٔ عمر معامله؛
• طرف مقابل (counterparty): نام، نشانی، نوع پرداخت، شناسه‌های مرجع، تاریخ تسویه و نوع تحویل.

چرخهٔ عمر معامله (Trade life cycle)

1. پیش از اجرا (pre-execution): ثبت سفارش؛
2. اجرا و ثبت (execution and booking): تطبیق سفارش و تبدیل آن به معامله؛ قرارداد بین طرفین شکل می‌گیرد؛
3. تأیید (confirmation): توافق دو طرف بر جزئیات؛
4. پس از ثبت (post booking): بررسی و راستی‌آزمایی صحت معامله؛
5. تسویه (settlement): مهم‌ترین مرحله، که در آن معامله نهایی می‌شود؛
6. پایان روز (overnight): گزارش‌گیری، محاسبه سود و زیان و ریسک.

کارکردهای سازمانی درگیر معمولاً به front office، middle office و back office تقسیم می‌شوند.

پیش‌دستان سفارش و دست‌کاری بازار

• پیش‌دستان سفارش (order anticipators) با پیش‌بینی اثر معاملات دیگران بر قیمت، پیش از آن‌ها سود می‌برند؛ نمونه‌ها: frontrunnerها، معامله‌گران فنی احساسی و squeezerها.
• دست‌کاری بازار (market manipulation) در بسیاری از کشورها غیرقانونی است: انتشار اطلاعات نادرست، ایجاد کمبود مصنوعی سهام یا تصور فعالیت کاذب برای سودجویی غیرقانونی.

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

جمع‌بندی

• رمزنگاری نامتقارن با زوج‌کلید عمومی/خصوصی نیاز به تبادل مخفی کلید را حذف می‌کند و برای رمز، تبادل کلید و امضا کاربرد دارد؛ در عوض کندتر از رمزنگاری متقارن است.
• امنیت آن بر مسائل ریاضی سخت استوار است: تجزیه (RSA)، لگاریتم گسسته (Diffie-Hellman) و لگاریتم گسسته روی منحنی بیضوی (ECC).
• ECC با کلیدهای بسیار کوچک‌تر (۲۵۶ بیت در برابر ۳۰۷۲ بیت RSA) همان امنیت را می‌دهد؛ secp256k1 منحنی استفاده‌شده در بیت‌کوین است و ECDSA الگوریتم امضای آن.
• توابع هش (SHA-256 در بیت‌کوین، Keccak در اتریوم، RIPEMD-160 برای آدرس) دارای سه ویژگی مقاومت (پیش‌تصویر، پیش‌تصویر دوم، برخورد) و اثر بهمنی‌اند.
• هش در ساختارهایی مانند درخت مرکل، درخت مرکل-پاتریشیا و DHT هستهٔ بلاک‌چین است؛ و MAC/HMAC نسخهٔ کلیددار و متقارن آن هستند.
• امضای دیجیتال (RSA، DSA، ECDSA) اصالت، جعل‌ناپذیری و عدم انکار را فراهم می‌کند؛ تراکنش‌ها با آن مالکیت را اثبات می‌کنند. در ECDSA تصادفی و یکتا بودن کلید موقت حیاتی است.
• مفاهیم پیشرفته (همومورفیک، signcryption، ZKP/ZK-SNARK، امضای کور و base58/base64) در حریم خصوصی و پول دیجیتال بلاک‌چین نقش دارند.
• بخش پایانی با اصطلاحات بازارهای مالی (سفارش‌ها، چرخهٔ عمر معامله، دست‌کاری بازار) زمینه را برای کاربردهای مالی بلاک‌چین می‌چیند. فصل بعد به بیت‌کوین، نخستین بلاک‌چین، می‌پردازد.

فصل ۵ — معرفی بیت‌کوین (Introducing Bitcoin)

مقدمه

بیت‌کوین (Bitcoin) نخستین کاربرد فناوری بلاک‌چین است و این فصل آن را از چند زاویه معرفی می‌کند: پیشینهٔ تاریخی ایده‌های پول دیجیتال، تعریف بیت‌کوین، نگاه کلی از دید کاربر، کلیدها و آدرس‌ها، تراکنش‌ها و زبان اسکریپت، ساختار بلاک‌چین و در پایان ماینینگ.

• بیت‌کوین نخستین ارز دیجیتال کاملاً تمرکززدایی‌شده (decentralized) است و از نظر شبکه و پروتکل بسیار امن و پایدار بوده است؛ هرچند خود ارز بیت‌کوین پرنوسان است.
• نویسنده به‌طور مشخص می‌گوید ارزش بازار آن در زمان نگارش حدود ۱۵۰ میلیارد دلار بود؛ قیمت حدود ۹٬۲۵۰ دلار؛ و قراردادهای آتی بیت‌کوین (Bitcoin Futures) در بورس CME شیکاگو معامله می‌شد.
• مخترع آن ساتوشی ناکاموتو (Satoshi Nakamoto) نامی مستعار است و هویت واقعی‌اش ناشناخته مانده؛ مقالهٔ معرفی بیت‌کوین در سال ۲۰۰۸ منتشر شد.

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

پول دیجیتال دهه‌ها موضوع پژوهش بوده است. فصل مسیر زیر را مرور می‌کند:

جمع‌بندی مؤلف: همهٔ این طرح‌ها هوشمندانه بودند ولی هرکدام از جایی ضعف داشتند؛ مشترک آن‌ها اتکا به یک سرور مرکزی مورد اعتماد بود.

بیت‌کوین

• در ۲۰۰۸ مقالهٔ «Bitcoin: A Peer-to-Peer Electronic Cash System» منتشر شد. ایدهٔ اول آن، پول الکترونیکی صرفاً همتا‌به‌همتا (peer-to-peer) بدون بانک واسط است.
• بیت‌کوین بر دهه‌ها پژوهش (درخت مرکل، توابع هش، رمزنگاری کلید عمومی، امضای دیجیتال) و ایده‌هایی چون BitGold، B-money، hashcash و زمان‌نگاری رمزنگاری‌شده (timestamping) بنا شده و آن‌ها را هوشمندانه ترکیب کرده است.
• نوآوری اصلی: راه‌حلی ظریف برای مسئلهٔ ژنرال‌های بیزانسی (Byzantine Generals’ Problem) و راه‌حل عملی برای دوبار خرج‌کردن (فصل ۱ را ببینید).
• ارزش بیت‌کوین از ۲۰۱۱ و به‌ویژه از مارس ۲۰۱۷ به‌شدت بالا رفته است (کتاب نمودار قیمت دارد).

مقررات‌گذاری و عوامل رشد

• مقررات‌گذاری بحث‌برانگیز است. برای اهل آزادی‌خواهی (libertarian) بیت‌کوین جایگزین بانک است، ولی قوانین ممکن است آن را به نهادی دیگر و غیرقابل‌اعتماد تبدیل کنند. نمونه: BitLicense ایالت نیویورک، مجوزی برای کسب‌وکارهای فعال در ارز مجازی؛ هزینه و سخت‌گیری آن باعث شد شرکت‌هایی از نیویورک خارج شوند.
• ایدهٔ اولیه یعنی پولی بدون طرف سوم مورد اعتماد و با امکان ناشناسی؛ الزام‌های KYC و اطلاعات تفصیلی ممکن است برای برخی جذابیت را کم کند.
• SEC آمریکا اعلام کرد توکن‌ها، سکه‌ها و ICOها در دستهٔ اوراق بهادارند و پلتفرم‌های معاملاتی باید ثبت شوند؛ قیمت بیت‌کوین همان روز حدود ۱۰٪ افتاد.
• اثر شبکه‌ای (network effect، صرفه‌های مقیاس سمت تقاضا): هرچه کاربران بیشتر باشند، ارزش شبکه بیشتر است. به‌علاوه کمیابی (سقف ۲۱ میلیون واحد) و نصف‌شدن پاداش ماینر هر چهار سال، به ارزش آن کمک می‌کند.

تعریف بیت‌کوین

بیت‌کوین هم پروتکل، هم ارز دیجیتال و هم پلتفرم است: ترکیبی از شبکهٔ همتا‌به‌همتا، پروتکل‌ها و نرم‌افزاری که ساخت و استفاده از ارز را ممکن می‌کند. قاعدهٔ نگارش: «Bitcoin» با B بزرگ یعنی پروتکل و «bitcoin» با b کوچک یعنی خود واحد پول.

مسئلهٔ دوبار خرج‌کردن (مثلاً فرستادن همزمان یک سکه به دو نفر که هر دو مستقل معتبر تشخیص داده شوند) در بیت‌کوین با دفتر کل توزیع‌شده (بلاک‌چین) که هر تراکنش را برای همیشه ثبت می‌کند، به‌علاوه سازوکار اعتبارسنجی و تأیید (ماینینگ) حل شده است.

بیت‌کوین در یک نگاه کلی

اجزای اصلی سیستم:

1. کلیدهای دیجیتال (Digital keys)
2. آدرس‌ها (Addresses)
3. تراکنش‌ها (Transactions)
4. بلاک‌چین (Blockchain)
5. ماینرها (Miners)
6. شبکهٔ بیت‌کوین
7. کیف پول‌ها (نرم‌افزار کلاینت)

فرستادن پرداخت به دیگری (مثال با کیف پول موبایل Blockchain)

1. گیرنده آدرس خود را (از طریق ایمیل، پیامک، چت یا هر کانال دیگر) می‌دهد؛ یا فرستنده خودش انتقال را آغاز می‌کند. در هر دو حالت آدرس دریافت‌کننده لازم است.
2. فرستنده آدرس را وارد یا QR code را اسکن می‌کند. QR شامل آدرس، مبلغ و توضیح اختیاری است و برنامه آن را به دستوری چون «ارسال مبلغ X به آدرس Y» تبدیل می‌کند. در مثال کتاب: ۰٫۰۰۰۳۳۳۲۴ BTC به آدرسی که با 1Jzou… شروع می‌شود؛ QR در قالب یک URL از نوع bitcoin://<address>?amount=… رمزگشایی می‌شود.
3. کیف پول تراکنش را با رعایت قواعد می‌سازد، با کلید خصوصی فرستنده امضا و در شبکه پخش می‌کند.
4. در صفحهٔ ارسال فیلدهایی چون From، To، BTC و Fee دیده می‌شود. کارمزد بر اساس اندازهٔ تراکنش و نرخ کارمزد (ساتوشی بر بایت) که به ازدحام شبکه بستگی دارد محاسبه می‌شود و تضمین‌کنندهٔ توجه ماینرها است.
5. نویسنده یادآوری می‌کند که در دورانی کارمزدها آنقدر بالا بود که حتی تراکنش‌های کوچک هم هزینهٔ زیادی داشتند؛ چون ماینرها تراکنش‌های پرکارمزدتر را برمی‌دارند و رقابت شدید بود. کیف پول معمولاً کارمزد را خودکار تخمین می‌زند.
6. پس از ارسال، تراکنش با وضعیت «در انتظار تأیید» (pending confirmation) نشان داده می‌شود؛ تأییدها با ورود به بلاک شروع می‌شوند و کارمزد از مبلغ کسر و به ماینر پرداخت می‌شود.

مثال مصور کتاب: پرداخت ۰٫۰۰۱۲۶۷ BTC (حدود ۱۱ دلار) به گیرنده و کارمزد ۰٫۰۰۰۱۰۶۲۲ BTC (حدود ۹۵ سنت) به‌عنوان کارمزد ماینینگ.

فیلدهای نمای خلاصهٔ تراکنش در explorer (Blockchain.info):

شناسهٔ تراکنش نمونه (d28ca5a5…6a1d) پس از ارسال در کیف پول در دسترس است و با explorerهای آنلاین قابل بررسی است. تراکنش‌ها برای انتقال در شبکه سریالایز و به هگزادسیمال کدگذاری می‌شوند (کتاب رشتهٔ هگز تراکنش نمونه را نشان می‌دهد و بعداً آن را رمزگشایی می‌کند).

مراحل پرداخت به‌طور خلاصه:

1. فرستنده تراکنش را با کلید خصوصی امضا می‌کند.
2. تراکنش سریالایز می‌شود.
3. در شبکه پخش (broadcast) می‌شود.
4. ماینرهایی که گوش می‌دهند آن را برمی‌دارند.
5. اعتبار آن را بررسی می‌کنند.
6. به بلاک کاندید می‌افزایند.
7. پس از استخراج، نتیجه به همهٔ گره‌ها پخش می‌شود.

واحدهای بیت‌کوین

بیت‌کوین مقادیر خردتر را هم می‌پذیرد و کوچک‌ترین واحد آن ساتوشی (Satoshi) است (یک صدمیلیونیوم bitcoin). کتاب جدول واحدها را به‌صورت تصویر آورده است.

کلیدها و آدرس‌های دیجیتال

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

کلیدهای خصوصی

• کلید خصوصی عددی ۲۵۶ بیتی است که تصادفی در بازهٔ تعیین‌شده توسط منحنی secp256k1 انتخاب می‌شود: از 0x1 تا اندکی کمتر از 0xFFFF…FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140. هر عدد در این بازه کلید معتبر است.
• برای تسهیل کپی و استفاده، کلید خصوصی معمولاً با WIF (Wallet Import Format) کدگذاری می‌شود و تبدیل دوسویه ممکن است. مثال کتاب: کلید هگز A3ED7E…5201 به رشته‌ای مثل L2iN7umV7… تبدیل می‌شود.
• کلید خصوصی کوچک (mini private key / minikey): حداکثر ۳۰ کاراکتر، همیشه با حرف بزرگ S شروع می‌شود؛ مناسب جاهایی با فضای فیزیکی محدود مثل حک‌کردن روی سکه یا QR مقاوم در برابر آسیب (چون نقاط بیشتری صرف تصحیح خطا می‌شود). تبدیل minikey به کلید کامل ممکن است ولی عکسش نه. این قالب در سکه‌های فیزیکی Casascius استفاده می‌شد.
• Bitcoin Core امکان رمزنگاری کیف پول حاوی کلیدهای خصوصی را هم دارد.

کلیدهای عمومی

• کلید عمومی از کلید خصوصی مشتق می‌شود (رابطهٔ ریاضی یک‌طرفه) و روی بلاک‌چین برای همه قابل مشاهده است. گره‌ها با آن بررسی می‌کنند تراکنش واقعاً با کلید خصوصی متناظر امضا شده، و این مالکیت را ثابت می‌کند.
• بیت‌کوین از ECC بر پایهٔ استاندارد secp256k1 و الگوریتم ECDSA استفاده می‌کند.
• کلید عمومی در اصل مختصات x و y یک نقطه روی منحنی است. در قالب غیرفشرده با پیشوند 0x04 و ۶۵ بایت؛ در قالب فشرده فقط x و یک بیت زوج/فرد‌بودن y و ۳۳ بایت. (کتاب مختصات را «۳۲ بیتی» گفته، ولی منظور ۳۲ بایت است.) دلیل کارکرد: منحنی نسبت به محور x متقارن است و از روی x می‌توان y را بازیابی کرد.
• پیشوندها: 0x04 غیرفشرده؛ 0x02 فشرده با y زوج؛ 0x03 فشرده با y فرد.
• از Bitcoin Core نسخهٔ ۰٫۶ قالب فشرده استاندارد شد که حدود ۵۰٪ صرفه‌جویی در فضای ذخیرهٔ کلیدهای عمومی بلاک‌چین ایجاد کرد.

آدرس‌ها

• ساخت آدرس: کلید عمومی ← هش با SHA-256 ← هش با RIPEMD-160 (نتیجه ۱۶۰ بیت) ← افزودن شمارهٔ نسخه (version) ← کدگذاری Base58Check. آدرس‌ها ۲۶ تا ۳۵ کاراکتر دارند و با ۱ یا ۳ شروع می‌شوند. مثال: 1ANAguGG8bikEv2fYsTBnRUmx7QUcK58wt که معمولاً به‌شکل QR code هم پخش می‌شود.
• دو نوع آدرس رایج: P2PKH (شروع با ۱) و P2SH (شروع با ۳). نوع قدیمی Pay to Pubkey منسوخ شده ولی هنوز برای آدرس‌های coinbase به کار می‌رود.
• هر آدرس نباید بیش از یک بار استفاده شود وگرنه مشکلات حریم خصوصی و امنیت پیش می‌آید. نویسنده به چند مسئلهٔ امنیتی دیگر هم اشاره می‌کند: انعطاف‌پذیری تراکنش (transaction malleability)، حمله Sybil، حملهٔ race و استخراج خودخواهانه (selfish mining). مشکل malleability با ارتقای نرم Segregated Witness (SegWit) حل شد.
• کتاب مثالی از کیف پول کاغذی (bitaddress.org) نشان می‌دهد که کلید خصوصی و آدرس را روی کاغذ دارد.

کدگذاری Base58Check

مجموعهٔ ۵۸ نماد الفبایی‌عددی که از کاراکترهای مبهم 0, O, I, l (که در فونت‌ها شبیه‌اند) پرهیز می‌کند. دلایل ذکرشده در کد منبع Bitcoin Core: عدم امکان ساخت داده‌های ظاهراً یکسان؛ پذیرش راحت‌تر رشته‌های بدون علائم؛ نشکستن خط در ایمیل؛ و انتخاب کل رشته با دابل‌کلیک. (در مقایسه با base64.)

آدرس‌های vanity

چون آدرس‌ها بر پایهٔ base58 هستند، می‌توان با جستجوی brute-force آدرس‌هایی ساخت که پیام یا کلمهٔ خوانایی دارند. مثال با ابزار bitcoinvanitygen.com و کیف پول کاغذی با آدرس vanity.

آدرس‌های چندامضایی (Multisignature)

برای آزادسازی سکه‌ها به چند امضا نیاز دارند؛ M-of-N MultiSig: M آستانهٔ حداقل امضاها از میان N کلید است.

تراکنش‌ها

• تراکنش هستهٔ اکوسیستم است؛ از ساده (ارسال به یک آدرس) تا پیچیده. هر تراکنش حداقل یک ورودی و یک خروجی دارد. ورودی‌ها سکه‌هایی‌اند که خرج می‌شوند (ساخته‌شده در تراکنش قبلی) و خروجی‌ها سکه‌هایی که ساخته می‌شوند. سکه‌ها در واقع UTXO ها هستند و بر حسب ساتوشی بیان می‌شوند.
• تراکنشی که سکهٔ جدید می‌سازد ورودی ندارد و امضا نمی‌خواهد؛ تراکنش انتقال باید توسط فرستنده امضا شود و ارجاعی به تراکنش قبلی برای نشان‌دادن منشأ سکه داشته باشد.
• تراکنش‌ها رمزنگاری نمی‌شوند و روی بلاک‌چین علنی‌اند.

چرخهٔ عمر تراکنش

1. کاربر با کیف پول یا رابط دیگری تراکنش می‌فرستد.
2. کیف پول با کلید خصوصی امضا می‌کند.
3. تراکنش با الگوریتم flooding در شبکه پخش می‌شود.
4. ماینرها اعتبارسنجی می‌کنند و به بلاک بعدی می‌افزایند؛ پیش از قرارگرفتن در بلاک، در بافر حافظه‌ای به نام transaction pool نگهداری می‌شود.
5. ماینینگ آغاز می‌شود (تأمین امنیت بلاک‌چین و تولید سکه به‌عنوان پاداش).
6. ماینر با حل اثبات کار، بلاک را پخش می‌کند.
7. گره‌ها بلاک را بررسی و منتشر می‌کنند و تأییدها شروع می‌شود.
8. در کیف پول گیرنده تأییدها ظاهر می‌شود؛ حدود ۳ تأیید معمولاً کافی است (توصیه ۳ تا ۶؛ حتی یک تأیید هم می‌تواند نهایی تلقی شود). منطق: پس از ۳ تأیید احتمال double spending عملاً ناچیز است.

کارمزد تراکنش

• کارمزد را ماینرها می‌گیرند و به اندازه و وزن تراکنش بستگی دارد. فرمول: fee = sum(inputs) − sum(outputs).
• کارمزد انگیزهٔ ماینر برای گنجاندن تراکنش است؛ همهٔ تراکنش‌ها به memory pool می‌روند و ماینر بر اساس اولویت از آن برمی‌دارد. کارمزد بیشتر یعنی زودتر برداشته شدن.
• کارمزد توسط پروتکل ثابت و اجباری نیست؛ تراکنش بدون کارمزد هم نهایتاً پردازش می‌شود ولی ممکن است بسیار طول بکشد. به‌دلیل حجم بالای تراکنش‌ها عملاً همیشه باید کارمزد داد. زمان تأیید از حدود ۱۰ دقیقه تا بیش از ۱۲ ساعت متغیر است و به کارمزد و شلوغی شبکه بستگی دارد. قواعد کارمزد برای ارسال، گنجاندن در بلاک و رله‌شدن توسط گره‌ها متفاوت است.

استخرهای تراکنش (Transaction pools)

یا memory pool؛ فهرست موقت تراکنش‌های تأییدنشده در RAM هر گره. پس از اعتبارسنجی و بر اساس اولویت وارد بلاک می‌شوند.

ساختار دادهٔ تراکنش

کتاب تراکنش نمونهٔ قبلی را به‌صورت JSON رمزگشایی‌شده نشان می‌دهد: اندازهٔ ۲۲۶ بایت، نسخهٔ ۱، lock_time صفر، یک ورودی، و دو خروجی؛ خروجی اول ۳۳٬۳۲۴ ساتوشی به آدرس 1Jzou… و خروجی دوم ۹۳٬۳۷۶ ساتوشی (بازگشت باقی‌مانده) به آدرس 1ET3o…، هر دو با اسکریپت OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG. (جمع ورودی منهای این دو، همان کارمزد است.)

متادیتا: اندازه، تعداد ورودی/خروجی، هش تراکنش، lock_time و پیشوند نسخه.

ورودی‌ها: هر ورودی معمولاً یک خروجی قبلی را خرج می‌کند؛ هر خروجی تا زمانی که ورودی‌ای آن را مصرف نکرده UTXO است.

خروجی‌ها: سه فیلد: Value (۸ بایت، تعداد ساتوشی)، Script size (۱ تا ۹ بایت) و Locking script (ScriptPubKey) که شرایط خرج‌شدن را مشخص می‌کند.

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

زبان اسکریپت (Script)

• یک زبان پشته‌ای (stack-based) ساده، با نحوی شبیه Forth و نمادگذاری لهستانی معکوس (RPN) که از چپ به راست با پشتهٔ LIFO ارزیابی می‌شود.
• تورینگ‌کامل نیست و حلقه ندارد تا اسکریپت‌های طولانی یا معلق روی شبکه اثر بد نگذارند.
• دستورها (opcode) در دسته‌هایی مثل ثابت‌ها، کنترل جریان، پشته، منطق بیتی، splice، حساب، رمزنگاری و lock time قرار دارند. چند opcode قدیمی به‌خاطر باگ‌ها منسوخ شده‌اند.
• تراکنش با ترکیب ScriptSig (اسکریپت باز، ارائه‌شده توسط خرج‌کننده) و ScriptPubKey (اسکریپت قفل، بخشی از خروجی) ارزیابی می‌شود: ابتدا باز می‌شود و سپس خرج می‌شود.

opcodeهای پرکاربرد:

انواع تراکنش

فقط تراکنش‌های استاندارد (قبول در IsStandard() و IsStandardTx()) معمولاً پخش یا استخراج می‌شوند؛ تراکنش‌های غیراستاندارد هم معتبرند.

• P2PKH — رایج‌ترین، برای ارسال به آدرس: ScriptPubKey = OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG؛ ScriptSig = <sig> <pubKey>. این دو به هم متصل و اجرا می‌شوند (کتاب نموداری از اجرای گام‌به‌گام دارد).
• P2SH — ارسال به هش اسکریپت (آدرس‌های ۳…)، استاندارد BIP16؛ علاوه بر اسکریپت، redeem script هم ارزیابی می‌شود: OP_HASH160 <redeemScriptHash> OP_EQUAL با ScriptSig شامل امضاها و redeemScript.
• MultiSig — M-of-N برای کاربردهایی چون escrow و سپرده: <m> <pubKey>… <n> OP_CHECKMULTISIG. شکل خام منسوخ است و معمولاً داخل redeem script در P2SH می‌آید.
• Pay to Pubkey — ساده: <PubKey> OP_CHECKSIG؛ کلید عمومی داخل اسکریپت است. منسوخ و مربوط به نسخه‌های قدیمی، ولی در coinbase رایج است.
• Null data / OP_RETURN — ذخیرهٔ دادهٔ دلخواه روی بلاک‌چین با پرداخت کارمزد؛ محدودیت ۴۰ بایت؛ خروجی خرج‌نشدنی است چون OP_RETURN همواره اعتبارسنجی را شکست می‌دهد و ScriptSig لازم نیست.

نمونهٔ bitcoin-cli getrawtransaction همان تراکنش نمونه را به‌شکل رشتهٔ هگز نشان می‌دهد.

تراکنش coinbase

• اولین تراکنش هر بلاک که ماینر می‌سازد و سکهٔ جدید خلق می‌کند. ورودی ویژه‌ای به نام coinbase دارد و حداکثر ۱۰۰ بایت داده دلخواه می‌پذیرد.
• در بلاک genesis، پیام معروف روزنامهٔ The Times (۳ ژانویهٔ ۲۰۰۹، دربارهٔ احتمال دومین بسته‌ی نجات بانک‌ها) در آن گنجانده شد که ثابت می‌کند بلاک قبل از آن تاریخ استخراج نشده است.
• ساختار ورودی coinbase: هش تراکنش همه‌صفر (۳۲ بایت)، اندیس خروجی 0xFFFFFFFF، طول داده (۲ تا ۱۰۰ بایت)، داده، و sequence برابر 0xFFFFFFFF.

قراردادها (Contracts)

بر اساس راهنمای توسعهٔ Bitcoin Core، قرارداد تراکنشی است که از سیستم بیت‌کوین برای اجرای یک توافق مالی استفاده می‌کند. با اسکریپت می‌توان escrow، داوری و کانال‌های ریزپرداخت ساخت؛ هرچند اسکریپت فعلی محدود است. نمونه: آزادسازی وجه فقط با امضای چند طرف (multisig) یا فقط پس از گذشت زمان معین (lock time).

اعتبارسنجی تراکنش

گره‌ها بر اساس راهنمای توسعه‌دهنده این بررسی‌ها را انجام می‌دهند (فهرست ۱۷ مورد کتاب، در خلاصه):

• درستی نحو و ساختار داده؛ ورودی/خروجی خالی نباشد؛ اندازه کمتر از حداکثر اندازهٔ بلاک باشد.
• مقدار خروجی در بازهٔ مجاز (۰ تا ۲۱ میلیون BTC).
• هر ورودی خروجی قبلی مشخص دارد (به‌جز coinbase که نباید رله شود)؛ nLockTime بیش از ۳۱ بیت نباشد.
• حداقل اندازه (۱۰۰ بایت)؛ تعداد عملیات امضا در تراکنش استاندارد محدود (طبق کتاب حداکثر دو)؛ رد تراکنش‌های غیراستاندارد.
• نبود تراکنش تکراری در pool یا شاخهٔ اصلی؛ رد تراکنش اگر خروجی ارجاعی در تراکنش دیگری از pool هم ارجاع شده باشد (double spend)؛ وجود خروجی خرج‌نشده برای هر ورودی؛ بلوغ ۱۰۰ تأییدی برای خروجی‌های coinbase.
• جمع مقادیر ورودی در بازه و کمتر از جمع خروجی‌ها نباشد؛ کارمزد حداقلی برای ورود به بلاک خالی؛ و درنهایت اسکریپت باز هر ورودی با اسکریپت قفل متناظر معتبر باشد.

انعطاف‌پذیری تراکنش (Malleability)

به‌دلیل یک باگ در پیاده‌سازی، مهاجم می‌توانست شناسهٔ تراکنش (txid) را پیش از تأیید تغییر دهد؛ در نتیجه به‌نظر می‌رسید تراکنش اجرا نشده و حملاتی مثل سپرده یا برداشت مضاعف ممکن می‌شد. (این مشکل با SegWit حل شد.)

بلاک‌چین

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

ساختار بلاک:

ساختار سرآیند (Block header):

(جدول کتاب در متن استخراج‌شده جابه‌جا شده؛ اندازه‌ها در بالا به شکل صحیح‌شان آمده‌اند.)

زنجیرشدن بلاک‌ها تضمین می‌کند هیچ تراکنشی بدون تغییر بلاک خودش و همهٔ بلاک‌های بعدی تغییرپذیر نیست. اولین بلاک genesis است و به بلاک قبلی لینک ندارد. نمودار کتاب نمای کلی زنجیره، سرآیند، محاسبهٔ ریشهٔ مرکل و ساختار تراکنش با اسکریپت قفل/باز را نشان می‌دهد.

بلاک genesis

در کد Bitcoin Core (فایل chainparams.cpp) سخت‌کد شده است؛ تابع CreateGenesisBlock پیام زمان‌نگاری The Times و اسکریپت خروجی با یک کلید عمومی و OP_CHECKSIG را دارد.

نکات تکمیلی دربارهٔ بلاک‌ها و زنجیره

• بیت‌کوین با قواعد سخت اعتبارسنجی و ماینینگ مانع double spending می‌شود. ارتفاع بلاک (block height) تعداد بلاک‌های پیش از یک بلاک است؛ ارتفاع در ۶ مارس ۲۰۱۸ حدود ۵۱۲٬۳۲۸ بود.
• خروجی coinbase تا ۱۰۰ بلاک قابل خرج نیست تا اگر بلاک بعداً stale شد مشکلی ایجاد نشود.
• بلاک stale: وقتی بلاکی حل شود و بقیهٔ ماینرها که هنوز روی پازل کار می‌کردند دیگر نیازی به کار روی آن نداشته باشند. بلاک orphan (یتیم/جدا‌شده): زمانی پذیرفته شده بود ولی با پیدایش زنجیر طولانی‌تری که آن را ندارد کنار گذاشته شد؛ مثلاً وقتی دو ماینر همزمان بلاک بسازند.
• آخرین نسخهٔ بلاک ۴ است (BIP65)، و از Core 0.11.2 با BIP9 بیت‌های فیلد nVersion برای اعلام تغییرات soft fork به کار می‌روند.
• فورک طبیعی وقتی دو بلاک معتبر همزمان اعلام شوند؛ شبکه با پذیرش طولانی‌ترین زنجیره حلش می‌کند. مهاجمی با ۵۱٪ توان هش می‌تواند تاریخچهٔ خودش را تحمیل کند.
• soft fork: سازگار با نسخه‌های قبلی؛ کلاینتی که ارتقا نداده هنوز کار می‌کند و فقط ماینرها باید ارتقا دهند. hard fork: بلاک‌های قبلاً معتبر را نامعتبر می‌کند و همه باید ارتقا دهند؛ تغییر ساختار بلاک یا تغییرات بزرگ پروتکل معمولاً hard fork است و انواع تراکنش جدید معمولاً با soft fork اضافه می‌شود.
• اندازهٔ بلاک‌چین در ۲۹ اکتبر ۲۰۱۷ حدود ۱۳۹ گیگابایت بود (نمودار رشد در کتاب).
• بلاک جدید تقریباً هر ۱۰ دقیقه اضافه می‌شود و سختی شبکه هر ۲۰۱۶ بلاک تنظیم می‌شود. فرمول کتاب: Target = Previous target × Time / (2016 × 10 minutes)، که در آن Time زمان واقعی تولید ۲۰۱۶ بلاک قبلی است. (کتاب آن را به‌صورت ساده‌شده نوشته است.) سختی و هدف معادل هم‌اند و میزان دشواری یافتن بلاک را می‌رسانند.

ماینینگ (Mining)

ماینینگ فرایند افزودن بلاک‌های جدید به بلاک‌چین است. گره‌های ماینر تراکنش‌ها را اعتبارسنجی و در بلاک جمع می‌کنند. این فرایند پرمصرف است چون ماینرها برای یافتن عددی کمتر از هدف سختی شبکه رقابت می‌کنند؛ مسئلهٔ «وارونه‌سازی جزئی هش» (partial hash inversion). همین هزینه گواه صرف منابع است، سکهٔ جدید خلق می‌کند و بلاک‌چین را در برابر تقلب و double spending ایمن می‌سازد.

• نرخ تولید حدود یک بلاک هر ۱۰ دقیقه و در پروتکل کدگذاری شده تا عرضهٔ پول کنترل شود.
• پاداش بلاک هر ۲۱۰٬۰۰۰ بلاک (تقریباً هر ۴ سال) نصف می‌شود: ۵۰ BTC در آغاز ← ۲۵ در ۲۰۱۲ ← ۱۲٫۵ در ژوئیهٔ ۲۰۱۶ ← حدود ۶٫۲۵ در halving بعدی (۲۰۲۰). (کتاب دو تاریخ برای آن آورده است.)
• حدود ۱۴۴ بلاک در روز و (در پاداش ۱۲٫۵) حدود ۱٬۷۲۸ بیت‌کوین در روز. حدود سال ۲۱۴۰ تقریباً ۲۱ میلیون سکه کامل خلق می‌شود و پس از آن ماینرها فقط از کارمزد درآمد خواهند داشت.
• ماینرها پاداش بلاک + کارمزد تراکنش‌ها را می‌گیرند.

وظایف ماینر

1. همگام‌سازی با شبکه: دانلود بلاک‌چین از دیگر گره‌ها (فقط مختص ماینر نیست).
2. اعتبارسنجی تراکنش: بررسی امضاها و خروجی‌ها.
3. اعتبارسنجی بلاک: ارزیابی بلاک‌های دریافتی با قواعد، شامل هر تراکنش و مقدار nonce.
4. ساخت بلاک جدید: ترکیب تراکنش‌های اعتبارسنجی‌شده.
5. انجام اثبات کار: تغییر مکرر nonce ۳۲ بیتی تا هش از هدف کمتر شود.
6. دریافت پاداش: پخش نتیجه؛ پذیرش توسط دیگران؛ پاداش (۱۲٫۵ BTC در زمان کتاب) + کارمزدها. احتمال کمی هست که بلاک به‌خاطر برخورد با بلاک همزمان دیگر پذیرفته نشود.

اثبات کار (PoW)

گواهی بر صرف منابع محاسباتی کافی برای ساخت بلاک معتبر. ایده: در هر دور یک گره تصادفی برای ساخت بلاک برگزیده می‌شود و گره‌ها متناسب با توان محاسباتی‌شان شانس می‌گیرند. شرط:

H(N ‖ P_hash ‖ Tx ‖ Tx ‖ … ‖ Tx) < Target

که N نانس، P_hash هش بلاک قبلی، Tx تراکنش‌ها و Target هدف سختی است. تنها راه یافتن نانس brute force است و وقتی ماینری هشی با الگوی صفرهای لازم یافت، بلاک پخش و پذیرفته می‌شود.

الگوریتم ماینینگ:

1. گرفتن سرآیند بلاک قبلی از شبکه.
2. جمع‌کردن مجموعه‌ای از تراکنش‌ها در بلاک پیشنهادی.
3. محاسبهٔ هش دوبل SHA-256 سرآیند همراه با نانس و بلاک.
4. اگر هش کمتر از هدف بود، PoW حل شده؛ بلاک پخش و پاداش گرفته می‌شود.
5. وگرنه نانس را افزایش بده و تکرار کن.

با رشد نرخ هش، فضای نانس ۳۲ بیتی خیلی سریع تمام شد؛ راه‌حل extra nonce است که از تراکنش coinbase به‌عنوان منبع نانس اضافی استفاده می‌کند تا بازهٔ جستجو بزرگ‌تر شود. (کتاب فلوچارت فرایند را دارد.)

سختی و نرخ هش

• با bitcoin-cli getdifficulty سختی فعلی خوانده می‌شود (در کتاب مقدار حدود ۱٫۴۵×۱۰¹۲ ذکر شده). سختی هر دو هفته یا ۲۰۱۶ بلاک به‌روز می‌شود تا میانگین ۱۰ دقیقه برای هر بلاک حفظ شود.
• اگر ۲۰۱۶ بلاک سریع‌تر از دو هفته استخراج شود سختی بالا می‌رود و اگر کندتر، پایین می‌آید. سختی در یک سال گذشته به‌شدت افزایش یافته است (نمودار).
• نرخ هش (hash rate): تعداد هش در ثانیه؛ در مارس ۲۰۱۸ بر حسب اگزاهش و بیش از ۲۴ میلیارد میلیارد (۲٫۴×۱۰¹⁹) هش در ثانیه. با ورود ASICها و استخرهای ماینینگ این رقم نمایی بالا رفته است.

سخت‌افزار ماینینگ

استخرهای ماینینگ

گروهی از ماینرها برای استخراج یک بلاک همکاری می‌کنند؛ مدیر استخر تراکنش coinbase را دریافت و پاداش را بین اعضا تقسیم می‌کند، حتی اگر عضو خاصی خودش پازل را حل نکرده باشد (درآمد پایدارتر از solo mining). مدل‌های پرداخت: PPS (Pay Per Share؛ مبلغ ثابت به شرکت‌کنندگان) و متناسب (proportional؛ بر اساس منابع صرف‌شده). استخرهای تجاری مثل AntPool، BTC.com و BTC TOP خدمات ابری ارائه می‌کنند (نمودار سهم هش استخرها در اکتبر ۲۰۱۷).

تمرکز و حمله ۵۱٪: اگر استخری بیش از ۵۱٪ نرخ هش را داشته باشد می‌تواند double spending کند، اجماع را مختل و تاریخچهٔ دلخواه تحمیل کند. این اتفاق یک بار (استخر GHash.IO) رخ داد. راه‌حل نظری، two-phase PoW است که با پازل دوم استخرهای بزرگ را وادار می‌کند کلید خصوصی خود را فاش کنند یا بخش بزرگی از توان هش را کنار بگذارند.

اقتصاد ماینینگ

سودآورترین روش ASIC است (Antminer، AvalonMiner، Whatsminer). ماینینگ انفرادی بدون سرمایه و انرژی زیاد توجیه ندارد. مثال مارس ۲۰۱۸: با ۱۲ TH/s فقط حدود ۰٫۰۰۰۹۱۷ BTC (~۶ دلار) در روز. Antminer S9 با ۱۳٫۵ TH/s حدود ۱۷۰۰ پوند قیمت دارد و با احتساب برق، بازگشت سرمایه نزدیک یک سال (حدود ۰٫۳ BTC تولید) طول می‌کشد؛ ولی چون سختی مدام زیاد می‌شود و دستگاه ظرف چند ماه کارایی‌اش را از دست می‌دهد، سرمایه‌گذاری ریسکی است.

جمع‌بندی

فصل با تاریخچهٔ طرح‌های پیشین پول دیجیتال (Chaum، e-cash، hashcash، B-money، BitGold، RPoW) شروع شد و نشان داد بیت‌کوین با حذف سرور مرکزی مورد اعتماد و ترکیب اثبات کار، امضای دیجیتال، هش و دفتر کل توزیع‌شده راه‌حل عملی ارائه کرد. سپس دیدیم یک پرداخت از دید کاربر چگونه ساخته، امضا، پخش، اعتبارسنجی و در بلاک ثبت می‌شود؛ کلید خصوصی (۲۵۶ بیتی، secp256k1، WIF)، کلید عمومی (فشرده ۳۳ بایت / غیرفشرده ۶۵ بایت) و آدرس (SHA-256 + RIPEMD-160 + Base58Check، P2PKH و P2SH، vanity و چندامضایی) چگونه مالکیت را نمایندگی می‌کنند. تراکنش‌ها از ورودی (UTXO مصرف‌شده) و خروجی تشکیل می‌شوند، با اسکریپت پشته‌ای غیرتورینگ‌کامل قفل و باز می‌شوند و انواع استاندارد (P2PKH، P2SH، MultiSig، OP_RETURN، coinbase) دارند. بلاک‌چین زنجیره‌ای از بلاک‌ها با سرآیند ۸۰ بایتی است که با هش، ریشهٔ مرکل و nonce به هم متصل‌اند، با فورک‌های نرم و سخت و تنظیم سختی هر ۲۰۱۶ بلاک. در پایان ماینینگ و PoW، پاداش و halving (سقف ۲۱ میلیون)، تکامل سخت‌افزار از CPU تا ASIC، استخرها و خطر تمرکز ۵۱٪ بررسی شد. فصل بعد به شبکهٔ بیت‌کوین، کلاینت‌ها و کیف پول‌ها می‌پردازد.

فصل ۶ — شبکه و پرداخت‌های بیت‌کوین (Bitcoin Network and Payments)

مقدمه

این فصل به لایهٔ شبکه و کاربردی بیت‌کوین می‌پردازد: انواع گره‌ها، پروتکل پیام‌رسانی بین آن‌ها، کیف پول‌ها، روش‌های دریافت پرداخت، پیشنهادهای بهبود (BIP)، پروتکل‌ها و فورک‌هایی که برای رفع محدودیت‌های بیت‌کوین ساخته شده‌اند، و در پایان مقدمه‌ای کوتاه دربارهٔ خرید و فروش بیت‌کوین.

شبکهٔ بیت‌کوین

شبکهٔ بیت‌کوین یک شبکهٔ همتابه‌همتا (peer-to-peer) است که گره‌های آن تراکنش‌ها و بلاک‌ها را مبادله می‌کنند. دو دستهٔ اصلی گره وجود دارد:

• گره کامل (Full node): پیاده‌سازی کامل کلاینت Bitcoin Core با چهار کارکرد: کیف پول، ماینر، ذخیرهٔ کامل بلاک‌چین و مسیریابی شبکه. لازم نیست همهٔ این کارکردها هم‌زمان فعال باشند.
• گره SPV (Simple Payment Verification) یا کلاینت سبک: فقط کیف پول و مسیریابی شبکه را انجام می‌دهد و بلاک‌چین کامل را نگه نمی‌دارد.

نسخهٔ پروتکل در زمان کتاب ۷۰۰۱۵ بود که با Bitcoin Core نسخهٔ 0.13.2 معرفی شد.

انواع گره‌ها در عمل

• گره کامل بلاک‌چین: امن‌تر است و در انتشار بلاک‌ها نقش حیاتی دارد.
• گره مسیریاب خالص: فقط شبکه را مسیریابی می‌کند و نه ماینینگ می‌کند و نه کلید خصوصی نگه می‌دارد.
• ماینر تنها (solo miner): ماینینگ، ذخیرهٔ کامل زنجیره و مسیریابی را با هم انجام می‌دهد.
• سرورهای پروتکل استخر (pool protocol servers): گره‌های غیراستاندارد اما پرکاربرد در استخرهای ماینینگ که از پروتکل‌های جایگزین مانند Stratum استفاده می‌کنند؛ گره‌هایی که فقط هش حساب می‌کنند جواب‌هایشان را از طریق Stratum به استخر می‌فرستند. گره‌های «فقط ماینینگ» هم وجود دارند.
• کلاینت SPV: هنگام همگام‌سازی فقط هدر بلاک‌ها را دانلود می‌کند و در صورت نیاز تراکنش‌ها را از گره‌های کامل می‌خواهد. اثبات حضور تراکنش در بلاک با Merkle root درون هدر و یک Merkle branch انجام می‌شود.

Stratum پروتکلی خط‌به‌خط (line-based) است که روی سوکت TCP ساده و با JSON-RPC خوانا کار می‌کند و رایج‌ترین راه اتصال به استخرهاست. شبکه‌های مختلف بیت‌کوین (اصلی، تست و …) با magic value های متفاوتی مشخص می‌شوند که مبدأ شبکهٔ هر پیام را نشان می‌دهد.

پیام‌های پروتکل

در مجموع ۲۷ نوع پیام در پروتکل وجود دارد (و با رشد پروتکل بیشتر خواهد شد). پرکاربردترین‌ها:

کشف گره‌ها و همگام‌سازی بلاک‌ها

کشف همتایان

• گره Bitcoin Core هنگام راه‌اندازی ابتدا همتایان را کشف می‌کند: از DNS seed هایی که در کد کلاینت (فایل chainparams.cpp) ثابت و به‌دست اعضای جامعه نگهداری می‌شوند پرس‌وجو می‌کند و چند رکورد DNS نوع A دریافت می‌کند. نمونه‌ها: seedهای Pieter Wuille، Matt Corallo، Luke Dashjr، Christian Decker، Jonas Schnelli و Peter Todd.
• پورت پیش‌فرض TCP 8333 برای شبکهٔ اصلی و 18333 برای testnet است.
• ترتیب کار: گره A پیام version (شامل نسخه، سرویس‌ها، زمان، آدرس شبکه، nonce و …) می‌فرستد، گره B با version خودش پاسخ می‌دهد، سپس verack رد و بدل می‌شود و اتصال برقرار است. بعد از آن getaddr و addr برای یافتن همتایان ناشناخته مبادله می‌شود و هر طرف می‌تواند با ping زنده‌بودن اتصال را بسنجد.

دانلود اولیهٔ بلاک‌ها (IBD)

با headers-first زمان همگام‌سازی که روزها بود به چند ساعت رسید، چون «نقشهٔ کل زنجیره» (زنجیرهٔ هدرها) از قبل در دست است. روند: گره IBD پیام getheaders را (حاوی یک یا چند هش هدر؛ برای گره تازه فقط هش بلاک پیدایش) به گره Sync می‌فرستد؛ پاسخ تا ۲٬۰۰۰ هدر است. سپس هدرهای بیشتر را ادامه می‌دهد و هم‌زمان بلاک‌ها را با getdata از چند گره می‌گیرد. اگر گره‌ای هدر بیشتری نداشت، از گره‌های دیگر پرسیده می‌شود. اگر زنجیره کاملاً همگام باشد، گره با پیام‌های inv منتظر بلاک جدید می‌ماند.

برای پشتیبانی از این تغییر، RPCهایی به‌روز شدند: getblockchaininfo (وضعیت زنجیره)، getpeerinfo (تعداد بلاک‌ها و هدرهای مشترک با همتایان) و getchaintips (فهرست همهٔ شاخه‌های شناخته‌شده شامل شاخه‌های فقط‌هدر).

مشاهده با Wireshark

ابزار Wireshark (با dissector بیت‌کوین) تبادل پیام‌ها را نشان می‌دهد: version، verack، getaddr، ping، addr و inv و نیز جزئیات هر بسته (نوع، نام فرمان، محتوا). توصیهٔ کتاب انجام این آزمایش‌ها روی testnet است. سه پیام اول در ضبط‌ها همان پروتکل کشف گره است.

کلاینت‌های SPV و Bloom filter

کلاینت کامل امن‌ترین روش اعتبارسنجی است. SPV فقط هدرهای بلندترین زنجیرهٔ معتبر را نگه می‌دارد و با Merkle branch وجود تراکنش را در بلاک بررسی می‌کند. این روش به‌تنهایی عملی نبود و با BIP 37 و فیلتر بلوم (Bloom filter) بهبود یافت.

• Bloom filter ساختاری احتمالاتی (بردار بیتی) برای آزمون عضویت است: مثبت کاذب دارد اما منفی کاذب ندارد؛ یعنی ممکن است عنصری غیرعضو را عضو بداند، اما عضو واقعی را هرگز رد نمی‌کند.
• عنصر با چند تابع هش به چند اندیس نگاشت و بیت‌ها ۱ می‌شوند؛ برای آزمون همان هش‌ها دوباره اعمال می‌شود. توابع باید سریع، مستقل و یکنواخت‌توزیع باشند؛ رایج‌ها FNV، Murmur و Jenkins (نه SHA-1).
• SPV با ساخت فیلتری که فقط تراکنش‌ها و Merkle block های مورد نیازش را تطبیق می‌دهد، پهنای باند کم مصرف می‌کند. Merkle block نسخهٔ سبک بلاک است: هدر، چند هش، فهرست پرچم‌های ۱ بیتی و تعداد تراکنش‌ها که برای بازسازی درخت Merkle کافی است.
• مبادلهٔ حریم خصوصی و دقت: فیلتر سخت‌گیرانه فقط موارد مرتبط را برمی‌گرداند اما احتمال لو رفتن آدرس‌ها و ارتباط آن‌ها با IP دارد؛ فیلتر شلوغ‌تر موارد نامرتبط بیشتری برمی‌گرداند ولی حریم خصوصی بهتری می‌دهد.
• BIP 37 سه پیام جدید افزود: filterload (تنظیم فیلتر روی اتصال)، filteradd (افزودن عنصر) و filterclear (حذف فیلتر).

کیف پول‌ها

نرم‌افزار کیف پول کلیدهای خصوصی/عمومی و آدرس‌ها را نگه می‌دارد و دریافت و ارسال را ممکن می‌کند. در Bitcoin Core فایل کیف پول (wallet.dat) یک پایگاه دادهٔ Berkeley DB است. کلید خصوصی یک عدد تصادفی ۲۵۶ بیتی است که برای امضای تراکنش‌های خروجی به کار می‌رود. نکتهٔ مهم: کیف پول سکه ذخیره نمی‌کند؛ در بیت‌کوین «سکه» وجود ندارد و فقط اطلاعات تراکنش‌ها (دقیق‌تر UTXOها) روی بلاک‌چین است که موجودی از آن‌ها محاسبه می‌شود.

انتخاب کیف پول به امنیت، سهولت استفاده و امکانات بستگی دارد، اما امنیت در اولویت اول است. کیف پول‌های سخت‌افزاری به‌دلیل طراحی ضدتخریب امن‌تر از وب‌ولت‌ها هستند، و کیف پول‌های موبایلی ترکیب متعادلی از امکانات و امنیت و محبوبیت زیادی دارند.

پرداخت‌های بیت‌کوین

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

• BIP 21 و URI: رشتهٔ نمایندهٔ اطلاعات پرداخت (آدرس و مبلغ). با کلیک روی لینک یا اسکن QR code پرداخت انجام می‌شود و تقریباً همهٔ کیف پول‌ها پشتیبانی می‌کنند. فروشگاه‌ها می‌توانند لوگوی «Bitcoin accepted here» را نصب کنند.
• پایانهٔ فروش (POS): راه‌حل‌هایی مانند XBTerminal و 34 Bytes. مراحل: فروشنده مبلغ را به ارز فیات وارد می‌کند؛ پایانه رسید حاوی QR و اطلاعات را چاپ می‌کند؛ مشتری با کیف پول موبایلش اسکن و به آدرس فروشنده می‌پردازد؛ پس از دریافت پرداخت، رسید فیزیکی نهایی چاپ می‌شود.
• پردازشگرهای پرداخت (Payment processors): سرویس‌هایی برای ادغام با فروشگاه‌های اینترنتی و گاهی نگهداری امن بیت‌کوین، مانند BitPay و Bitcoin Merchant Solutions.
• BIP 70 (Payment Protocol): ارتباط امن بین فروشنده و مشتری با گواهی‌های X.509 روی HTTP/HTTPS؛ سه پیام دارد: PaymentRequest، Payment و PaymentACK. مزایا: دفاع در برابر حملهٔ مرد میانی (که آدرس فروشنده را دستکاری می‌کند تا خریدار فریب بخورد) و اثبات پرداخت. BIP 71 (نوع‌های MIME) و BIP 72 (توسعهٔ URI) برای پشتیبانی از آن استاندارد شدند.
• شبکهٔ Lightning: راهکاری برای پرداخت‌های آنی و مقیاس‌پذیر خارج از زنجیره (off-chain) که از کانال‌های پرداخت استفاده می‌کند؛ از اوایل ۲۰۱۶ معرفی شد و سرعت و مقیاس‌پذیری بیت‌کوین را افزایش می‌دهد.

نوآوری در بیت‌کوین

بیت‌کوین همچنان در حال تحول است و کارایی (throughput) موضوع اصلی بحث بوده است. بهبودها یا به‌شکل BIP می‌آیند یا نسخه‌های بنیادین پروتکل که شبکهٔ جدید می‌سازند؛ برخی با سافت‌فورک قابل اجرا هستند و برخی به هارد‌فورک نیاز دارند که به ارز تازه می‌انجامد.

انواع BIP

• Standard BIP: تغییرات مهم و اثرگذار بر سیستم، مانند اندازهٔ بلاک، پروتکل شبکه یا اعتبارسنجی تراکنش.
• Process BIP: تغییر در فرایندهای بیرون از پروتکل هسته؛ فقط پس از اجماع کاربران پیاده‌سازی می‌شود.
• Informational BIP: توصیه یا ثبت اطلاعات دربارهٔ اکوسیستم، مثل مسائل طراحی.

مسئلهٔ کارایی

بیت‌کوین ذاتاً حدود ۳ تا ۷ تراکنش در ثانیه پردازش می‌کند؛ در مقایسه، Visa به‌طور میانگین حدود ۲۴٬۰۰۰، PayPal حدود ۲۰۰ و اتریوم حدود ۲۰ تراکنش در ثانیه (ارقام کتاب). علاوه بر آن، تغییرپذیری تراکنش (transaction malleability) نگرانی امنیتی است که می‌تواند به منع سرویس منجر شود.

Segregated Witness (SegWit)

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

• رفع malleability با جداکردن داده امضا از داده تراکنش، چون شناسهٔ تراکنش دیگر از امضا محاسبه نمی‌شود؛
• کوچک‌شدن تراکنش و کارمزد ارزان‌تر؛
• کاهش زمان امضا و تأیید؛
• نسخه‌بندی اسکریپت (script versioning) که بدون هارد‌فورک اجازهٔ بهبود زبان اسکریپت را می‌دهد؛
• کاهش زمان تأیید ورودی.

SegWit در BIP 141، 143، 144 و 145 تعریف شد و در ۲۴ اوت ۲۰۱۷ روی شبکهٔ اصلی فعال شد. به‌جای سقف سخت ۱ مگابایت، مفهوم block weight آمد؛ سقف نظری تا ۴ مگابایت است اما در عمل حدود ۱٫۶ تا ۲ مگابایت. در SegWit امضا بخشی از تراکنش اصلی نیست و جداگانه ارائه می‌شود. دو شیوهٔ جدید خرج کردن UTXO (نه نوع تراکنش تازه): P2WPKH (Pay to Witness Public Key Hash) و P2WSH (Pay to Witness Script Hash).

Bitcoin Cash

سقف بلاک را به ۸ مگابایت می‌رساند، با اجماع PoW و سخت‌افزار ASIC؛ بازهٔ بلاک از ۱۰ دقیقه به بازه‌ای بین ۱۰ ثانیه تا ۲ ساعت تغییر می‌کند (طبق متن کتاب) و محافظت در برابر replay و wipe-out دارد.

Bitcoin Unlimited

اندازهٔ بلاک سقف سخت ندارد و ماینرها در طول زمان بر سر حد آن به اجماع می‌رسند. دو ایدهٔ دیگر:

• Extreme thin blocks: گره درخواست‌کننده با getdata یک bloom filter از تراکنش‌های موجود در mempool خود می‌فرستد و فقط تراکنش‌های ناموجود را در بلاک «نازک» دریافت می‌کند؛ این از دریافت دوبارهٔ هر تراکنش (یک‌بار هنگام پخش و یک‌بار داخل بلاک) جلوگیری می‌کند.
• Parallel validation: اعتبارسنجی هم‌زمان چند بلاک و تراکنش‌های جدید؛ در بیت‌کوین معمولی گره هنگام اعتبارسنجی بلاک تازه نمی‌تواند تراکنش جدید رله کند یا بلاک دیگری بسنجد.

Bitcoin Gold

هارد‌فورکی از بلاک ۴۹۱٬۴۰۷ (در متن کتاب به‌اشتباه تایپی نوشته شده) که زنجیرهٔ جدید BTG را ساخت. هدف مقابله با متمرکز شدن ماینینگ بود. از الگوریتم Equihash استفاده می‌کند، بنابراین ضد ASIC است و با GPU ماین می‌شود.

پیشنهادهای دیگر (Bitcoin Next Generation، Solidus، Spectre، SegWit2x) در فصل ۱۸ (مقیاس‌پذیری) بررسی می‌شوند.

سرمایه‌گذاری، خرید و فروش بیت‌کوین

صرافی‌های آنلاین امکان خرید و فروش، معاملهٔ CFD، spread betting، معاملهٔ اهرمی و تبدیل به رمزارزهای دیگر را فراهم می‌کنند و داده‌های بازار، نمودار و راهبردهای معاملاتی ارائه می‌دهند (نمونه: CEX). معامله‌گر می‌تواند موقعیت long یا short باز کند.

دفتر سفارش (order book): سفارش‌های فروش را ask و سفارش‌های خرید را bid می‌نامند؛ ask قیمتی است که فروشنده می‌پذیرد و bid قیمتی که خریدار می‌پردازد. اگر قیمت‌ها منطبق شوند معامله رخ می‌دهد. دو نوع سفارش رایج:

• Market order: به‌محض تطبیق قیمت، فوراً اجرا می‌شود.
• Limit order: خرید/فروش مقدار مشخص با قیمت معین یا بهتر؛ می‌توان مدت اعتبار تعیین کرد و در صورت اجرا نشدن لغو می‌شود.

مباحث بیشتر دربارهٔ بازارهای مالی در فصل ۴ آمده است.

جمع‌بندی

• شبکهٔ بیت‌کوین ترکیبی از گره‌های کامل، SPV، ماینر و سرورهای استخر است که با پروتکل پیام‌ها (version، inv، getdata، headers و …) روی TCP (پورت ۸۳۳۳) با هم گفت‌وگو می‌کنند؛ کشف همتا از DNS seed و همگام‌سازی از 0.10.0 به‌صورت headers-first است.
• SPV با Merkle branch و فیلتر بلوم (BIP 37) سبک کار می‌کند، اما بین کارایی و حریم خصوصی مبادله وجود دارد.
• کیف پول‌ها از غیرقطعی تا HD، کاغذی، سخت‌افزاری، آنلاین و موبایلی هستند و امنیت معیار اصلی انتخاب است.
• پرداخت با URI/QR، POS، پردازشگرها، BIP 70 و Lightning انجام می‌شود.
• محدودیت کارایی و malleability به SegWit (سافت‌فورک) و فورک‌هایی مانند Bitcoin Cash، Bitcoin Unlimited و Bitcoin Gold انجامیده است.
• معاملهٔ بیت‌کوین در صرافی‌ها با دفتر سفارش و دو نوع سفارش market و limit انجام می‌شود.

فصل ۷ — کلاینت‌ها و APIهای بیت‌کوین (Bitcoin Clients and APIs)

مقدمه

این فصل عملی است: نصب کلاینت بیت‌کوین، راه‌اندازی گره در شبکهٔ اصلی و شبکه‌های آزمایشی، دستورهای خط فرمان و در پایان معرفی APIها و کتابخانه‌هایی که برای ساخت برنامه‌های بیت‌کوینی در دسترس‌اند.

نصب بیت‌کوین

کلاینت Bitcoin Core از سایت bitcoin.org قابل دانلود است و برای معماری‌ها و سیستم‌عامل‌های گوناگون (از x86 ویندوز تا ARM لینوکس) نسخه دارد.

انواع کلاینت Bitcoin Core

این راستی‌آزمایی اولیه مخصوص Bitcoin-qt نیست و Bitcoind هم آن را انجام می‌دهد.

راه‌اندازی یک گره

• روی Ubuntu: ابتدا sudo apt-get update و سپس نصب بستهٔ مورد نظر با apt-get install برای bitcoind یا bitcoin-qt یا هر دو. (نصب برای سایر پلتفرم‌ها در bitcoin.org شرح داده شده است.)
• از کد منبع: برای مشارکت در توسعه یا یادگیری می‌توان با git clone مخزن GitHub بیت‌کوین را گرفت (در مثال کتاب حدود ۷۸٬۹۶۰ شیء و حدود ۷۲٫۵ مگابایت)، وارد پوشه شد و با ./autogen.sh، ./configure و make و سپس sudo make install کامپایل و نصب کرد.
• فایل bitcoin.conf: تنظیمات کلاینت در آن ذخیره می‌شود. همهٔ گزینه‌های خط فرمان bitcoind (به‌جز سوئیچ -conf خودش) در این فایل قابل تنظیم‌اند و هر دو برنامهٔ Bitcoin-qt و Bitcoind هنگام اجرا آن را می‌خوانند. در لینوکس معمولاً در $HOME/.bitcoin/ است یا با -conf=<file> مشخص می‌شود.

راه‌اندازی در testnet

حالت testnet برای آزمایش است؛ سریع‌تر از شبکهٔ اصلی با قواعد سهل‌گیرانه‌تر برای ماینینگ و تراکنش. سرویس‌های faucet (مانند Bitcoin TestNet sandbox) بیت‌کوین آزمایشی به آدرس testnet کاربر می‌دهند. دستورها:

• bitcoind --testnet -daemon
• bitcoin-cli --testnet <command>
• bitcoin-qt --testnet

راه‌اندازی در regtest

حالت regtest (regression testing) یک بلاک‌چین محلی برای آزمون می‌سازد:

• اجرا با bitcoind -regtest -daemon؛
• تولید بلاک با bitcoin-cli -regtest generate 200 (در مثال، پس از آن موجودی ۸۷۵۰ بیت‌کوین بود که با getbalance دیده شد)؛
• لاگ‌ها در .bitcoin/regtest/debug.log در دسترس‌اند؛
• توقف گره با bitcoin-cli -regtest stop.

آزمایش با Bitcoin-cli

Bitcoin-cli از طریق رابط RPC کلاینت Core کار می‌کند. مثال‌های کتاب اجرای getinfo را نشان می‌دهند و فرمت مشابهی برای سایر دستورها دارد؛ و دستور راهنما فهرست همهٔ فرمان‌های موجود برای پرس‌وجو از بلاک‌چین و کنترل گره محلی را نمایش می‌دهد (خروجی آن طولانی است). از نسخهٔ 0.10.0 رابط HTTP REST نیز اضافه شده که به‌طور پیش‌فرض روی همان پورت TCP 8332 JSON-RPC کار می‌کند.

برنامه‌نویسی بیت‌کوین و رابط خط فرمان

Bitcoin Core فرمان‌های JSON-RPC متعددی ارائه می‌دهد که با اسکریپت یا برنامهٔ سفارشی می‌توان برای ساخت تراکنش خام (raw transaction) و کارهای دیگر استفاده کرد؛ Bitcoin-cli هم بر همین رابط سوار است.

APIهای سرویس‌دهنده

APIهای HTTP REST ساده نیز از سوی ارائه‌دهندگان آنلاین موجودند، مانند Blockchain.info، BitPay و Block.io.

کتابخانه‌ها

• Libbitcoin: ابزارها و کلاینت‌های خط فرمان قدرتمند؛
• Pycoin: کتابخانهٔ Python؛
• Bitcoinj: کتابخانهٔ Java.

APIهای آنلاین پرکاربرد: bitcore.io، bitcoinjs.org و blockchain.info/api.

انتخاب API

چون APIها قابلیت‌های مشابهی دارند، معرفی «بهترین» دشوار است. توصیهٔ کتاب: علاوه بر امکانات، حتماً امنیت طراحی API را ارزیابی کنید.

جمع‌بندی

• Bitcoin Core شامل سه جزء است: daemon (bitcoind)، ابزار خط فرمان (bitcoin-cli) و رابط گرافیکی (bitcoin-qt).
• نصب از بسته یا کد منبع ممکن است و تنظیمات در bitcoin.conf ذخیره می‌شود.
• برای آزمایش بی‌خطر می‌توان از testnet (شبکهٔ عمومی آزمایشی با faucet) یا regtest (زنجیرهٔ محلی با تولید فوری بلاک) استفاده کرد.
• برنامه‌نویسی با JSON-RPC و REST (پورت 8332)، کتابخانه‌هایی مانند Libbitcoin، Pycoin و Bitcoinj و سرویس‌های API انجام می‌شود، و امنیت باید معیار اصلی انتخاب API باشد.

فصل ۸ — ارزهای جایگزین (Alternative Coins)

مقدمه

بیت‌کوین در سال ۲۰۰۹ عرضه شد و نخستین پروژهٔ ارز جایگزین، Namecoin، در ۲۰۱۱ آمد. در ۲۰۱۳ و ۲۰۱۴ بازار «آلت‌کوین‌ها» (altcoin) به‌سرعت رشد کرد و پروژه‌های بسیار متنوعی شروع شد. تعداد کمی موفق شدند، بسیاری به‌دلیل بی‌توجهی بازار از میان رفتند، و بعضی هم صرفاً طرح‌های کلاهبرداری «پامپ و دامپ» (pump and dump) بودند که مدتی دیده شدند و ناپدید شدند.

نویسنده رویکردهای جایگزین بیت‌کوین را بر اساس هدف اصلی به دو دسته تقسیم می‌کند:

• زنجیره‌های جایگزین (alternative chains): هدف، ساختن یک پلتفرم بلاک‌چین غیرمتمرکز است (فصل ۱۶ کتاب).
• آلت‌کوین‌ها: هدف تنها معرفی یک ارز مجازی جدید است؛ محور همین فصل.

علاوه بر آلت‌کوین‌ها، فصل به پروتکل‌هایی هم می‌پردازد که روی بیت‌کوین ساخته می‌شوند و خدماتی غیر از ارز ارائه می‌دهند (مثل Namecoin برای نام‌گذاری و هویت غیرمتمرکز). مثال‌هایی از ارزهای دارای ارزش در زمان نگارش: Namecoin، Zcash و Primecoin. Zcash (۲۰۱۶) موفق‌تر بود؛ Primecoin محبوبیت زیادی نیافت اما هنوز استفاده می‌شود. بسیاری از این پروژه‌ها فورک مستقیم کد بیت‌کوین‌اند و برخی از صفر نوشته شده‌اند. بعضی به محدودیت‌های بیت‌کوین (مثل حریم خصوصی) پاسخ می‌دهند و بعضی نوع استخراج، زمان بلاک یا شیوهٔ توزیع را تغییر می‌دهند.

آلت‌کوین و هارد فورک

از نظر تعریف، هر هارد فورک (hard fork) یک ارز جدید می‌سازد: زنجیرهٔ قدیمی عملاً سکه‌ای دیگر محسوب می‌شود، هرچند قاعدهٔ ثابتی برای تعیین اینکه کدام شاخه «آلت» است وجود ندارد. نمونهٔ اتریوم: هارد فورک باعث پیدایش Ethereum Classic (ETC) در کنار Ether (ETH) شد؛ ETC زنجیرهٔ قدیمی و ETH زنجیرهٔ جدید است. نویسنده این‌گونه فورک‌های مناقشه‌برانگیز را نامطلوب می‌داند، به دو دلیل: (۱) با روح تمرکززدایی ناسازگار است چون نهادی مرکزی (بنیاد اتریوم) علی‌رغم مخالفت بخشی از جامعه تصمیم را پیش برد؛ (۲) جامعهٔ کاربران را دوپاره می‌کند. افزون بر این، فورک معمولاً پارامترهای بنیادین سکه را عوض نمی‌کند، پس برای داشتن پارامترها و ویژگی‌های دلخواه بهتر است ارز را از صفر نوشت یا کد بیت‌کوین (یا ارز دیگری) را فورک کرد.

جذب کاربر و توزیع اولیه

یک ارز بدون کاربر، معامله‌گر و ماینر ارزشی ندارد؛ ارزش ارزهای مجازی از اثر شبکه‌ای (network effect) و پذیرش جامعه می‌آید. برای جذب کاربران باید مقداری سکهٔ اولیه توزیع شود و این کار روش‌های مختلفی دارد (با ریسک از دست رفتن سرمایه اگر ارز شکست بخورد):

بازار

سرمایهٔ بازار مجموع آلت‌کوین‌ها در زمان نگارش بیش از ۲۰۰ میلیارد دلار بود (نمودار از coinmarketcap). جدول ده ارز برتر در مارس ۲۰۱۸:

نویسنده یادآور می‌شود بسیاری از مفاهیم (hashcash، اثبات کار) پیش از بیت‌کوین وجود داشتند، اما بیت‌کوین با حل مسألهٔ ژنرال‌های بیزانسی و ترکیب هوشمندانهٔ این ایده‌ها آن‌ها را به صحنه آورد؛ پروژه‌های آلت‌کوین هم تکنیک‌های جدیدی افزودند که برای فهم چشم‌انداز فعلی باید ابتدا مبانی نظری‌شان را شناخت.

مبانی نظری

جایگزین‌های اثبات کار

اثبات کار (PoW) در بیت‌کوین تضمین می‌کند ماینر کار لازم برای یافتن بلاک را انجام داده و از این راه تمرکززدایی، امنیت و پایداری فراهم می‌شود. ویژگی‌های مطلوب پازل‌های استخراج:

• progress freeness (بی‌حافظگی پیشرفت): پاداش مصرف منابع محاسباتی باید تصادفی و متناسب با سهم هر ماینر باشد، به‌طوری که حتی ماینر کم‌توان هم شانسی برای بردن داشته باشد (اصطلاحی از Narayanan و همکاران در کتاب Bitcoin and Cryptocurrency Technologies)؛
• سختی قابل تنظیم (adjustable difficulty) متناسب با رشد توان هش و تعداد کاربران؛
• راستی‌آزمایی سریع (quick verification).

مشکل: با ظهور ASICها (برای SHA-256 دوگانه)، قدرت به سمت ماینرها و استخرهایی می‌رود که فارم‌های بزرگ ASIC دارند و این با فلسفهٔ تمرکززدایی در تضاد است.

پازل‌های مقاوم در برابر ASIC

• پازل‌های سخت از نظر حافظه (memory-hard): چون حل پازل حافظهٔ زیادی می‌خواهد، پیاده‌سازی روی ASIC سخت یا ناکارآمد فرض می‌شود. نخستین بار در Litecoin و Tenebrix با تابع Scrypt استفاده شد. اما این ادعا نقض شد: حافظه ارزان‌تر شده و ساخت مدارهای نانومتری ممکن است؛ امروز ASICهای Scrypt موجود است.
• هش زنجیره‌ای (chained hashing): محاسبهٔ چند تابع هش پشت‌سرهم. مثال شاخص X11 در Dash است که ۱۱ الگوریتم از نامزدهای مسابقهٔ SHA-3 را به‌صورت زنجیره‌ای به کار می‌برد (BLAKE، BMW، Groestl، JH، Keccak، Skein، Luffa، CubeHash، SHAvite، SIMD و ECHO). در ابتدا مقاومت می‌کرد، ولی اکنون ماینرهای ASIC تجاری برای X11 و X13/X14/X15 (مانند Baikal، iBeLink DM384M و PinIdea) وجود دارد.
• پازل‌های خودتغییر‌دهنده (self-mutating): طرحی که الگوریتم یا نیازمندی‌های PoW را با گذر زمان، هوشمندانه یا تصادفی تغییر دهد تا ساخت ASIC بی‌معنا شود؛ عملی‌سازی آن هنوز روشن نیست.

مصرف انرژی و اثبات کار مفید

بزرگ‌ترین ایراد PoW مصرف انرژی است. در زمان نگارش، برآورد برق مصرفی ماینرهای بیت‌کوین بیشتر از کشوری مثل بنگلادش (حدود ۵۴٫۶۹ تراوات‌ساعت) و رد پای کربنی حدود ۳۸۷ کیلوگرم CO₂ به ازای هر تراکنش ذکر شده است؛ پیش‌بینی می‌شد تا پایان ۲۰۱۸ به حدود ۱۲۵ TWh در سال برسد (نمودار از digiconomist). راه‌حل پیشنهادی: اثبات کار مفید که علاوه بر اجماع، محاسبهٔ علمی هم انجام دهد. Primecoin این را پیاده کرده است: ماینرها زنجیره‌های خاص اعداد اول (Cunningham chains و bi-twin chains) را پیدا می‌کنند که برای مطالعهٔ توزیع اعداد اول (مثلاً در فیزیک) اهمیت دارد.

اثبات ذخیره‌سازی (Proof of Storage)

با نام اثبات بازیابی‌پذیری (proof of retrievability) هم شناخته می‌شود؛ نوعی کار مفید که ذخیرهٔ حجم زیادی داده را می‌طلبد. از Microsoft Research آمده و فایدهٔ آن ذخیرهٔ توزیع‌شدهٔ داده‌های آرشیوی است. ماینرها باید زیرمجموعه‌ای شبه‌تصادفی از داده‌های بزرگ را نگه دارند تا استخراج کنند.

اثبات سهام (PoS)

«استخراج مجازی» هم نامیده می‌شود؛ نخستین بار در Peercoin در اوت ۲۰۱۲ مطرح شد. کاربران باید مالکیت مقداری ارز را نشان دهند (سهم خود در سکه). ساده‌ترین شکل: استخراج برای دارندگان بیشتر آسان‌تر است. دو مزیت: به دست آوردن مقدار زیاد ارز نسبت به خرید ASIC پیشرفته دشوارتر است، و منابع محاسباتی صرفه‌جویی می‌شود.

انواع «سهام» که مطرح شده‌اند:

• اثبات عمر سکه (Proof of coinage): عمر سکه از آخرین باری که خرج یا نگهداری شد محاسبه می‌شود و با استخراج هر بلاک صفر می‌شود؛ ماینر برای نگه داشتن و خرج نکردن سکه پاداش می‌گیرد. Peercoin این را به شکل خلاقانه‌ای با PoW ترکیب کرده است: سختی پازل PoW با عمر سکه نسبت وارونه دارد، یعنی اگر ماینر با تراکنش coin-stake مقداری coinage مصرف کند، نیاز به PoW کمتر می‌شود.
• اثبات سپرده (Proof of Deposit, PoD): سکه‌های بلاک‌های تازه‌استخراج‌شده برای مدتی (تعداد معینی بلاک) قفل می‌شوند؛ ماینر به بهای منجمد کردن مقداری سکه استخراج می‌کند. نوعی PoS است.
• اثبات سوزاندن (PoB): نابود کردن مقداری بیت‌کوین (به‌جای صرف توان محاسباتی) برای دریافت معادل آلت‌کوین؛ برای توزیع منصفانهٔ اولیه در پروژه‌های جدید کاربرد دارد و ارزش سکه از همان سوختن قبلی می‌آید.
• اثبات فعالیت (Proof of Activity, PoA): ترکیبی از PoW و PoS. بلاک‌ها ابتدا با PoW تولید می‌شوند، سپس هر بلاک سه صاحب سهم را به‌صورت تصادفی انتخاب می‌کند که باید آن را امضا کنند؛ اعتبار بلاک‌های بعدی به امضای موفق قبلی‌ها وابسته است.

مشکل شناخته‌شدهٔ PoS: nothing at stake (چیزی برای از دست دادن نیست). در PoW استخراج روی چند شاخه هزینهٔ محاسباتی دارد، اما در PoS مهاجم می‌تواند با همان سکه روی چند زنجیره «استخراج» کند و فورک ساختن بی‌هزینه می‌شود.

پازل‌های غیرقابل برون‌سپاری (Nonoutsourceable puzzles)

انگیزه: مقابله با شکل‌گیری استخرهای استخراج. در استخر، اپراتور مرجعی مرکزی است که همهٔ پاداش‌ها به او می‌رسد و می‌تواند قواعدی تحمیل کند، و ماینرها فقط به‌خاطر هدف مشترک به هم اعتماد می‌کنند. در این پازل‌ها هر ماینر می‌تواند پاداش را برای خودش بردارد، بنابراین بی‌اعتمادی میان ماینرهای ناشناس تشکیل استخر را بعید می‌کند. نویسنده خاطرنشان می‌کند جایگزین‌های دیگر PoW در فصل ۱، ۱۵ و ۱۸ هم بحث شده‌اند و این حوزه همچنان در حال پژوهش است.

الگوریتم‌های تنظیم و بازتنظیم سختی

در بیت‌کوین سختی هر ۲۰۱۶ بلاک بازتنظیم می‌شود: اگر تولید ۲۰۱۶ بلاک بیش از دو هفته (زمان بین بلاک‌ها حدود ۱۰ دقیقه) طول بکشد سختی کم می‌شود و اگر کمتر، زیاد. فرمول مفهومی کتاب: سختی جدید متناسب با نسبت زمان واقعی به زمان هدف (۲۰۱۶ × ۱۰ دقیقه) است. با ورود ASICها سختی به‌شدت بالا رفت و این از ضعف PoWهای غیرمقاوم به ASIC است که به تمرکز قدرت استخراج می‌انجامد.

تهدیدهای ارزهای نوپا:

• اگر ارز جدیدی با همان SHA-256 شروع شود، یک مهاجم با ASIC می‌تواند کل شبکه را در دست بگیرد (به‌ویژه وقتی علاقهٔ ماینرهای دیگر کم باشد؛ اگر ماینرهای هم‌توان بیایند، رقابت خطر را کم می‌کند).
• مولتی‌پول‌ها (multipools) و pool hopping: گروهی از ماینرها خودکار به ارز سودآور می‌روند؛ فقط وقتی سختی پایین است می‌آیند و با بالا رفتن سختی می‌روند. مثلاً مولتی‌پولی که ارز جدید را سریع استخراج کند و سپس برود، شبکه را با سختی بسیار بالا و استخراج غیرسودآور برای ماینرهای انفرادی تنها می‌گذارد؛ تنها راه‌حل هارد فورک است که برای جامعه نامطلوب است.

الگوریتم‌های جدید همگی بر بازتنظیم پارامترهایی مثل تعداد بلاک‌های گذشته، سختی آن‌ها، نسبت تنظیم و حد بالا/پایین تغییر سختی به‌ازای تغییر نرخ هش استوارند:

محدودیت‌های بیت‌کوین

حریم خصوصی و گمنامی

بلاک‌چین دفتر کل عمومی است و تحلیلش ساده؛ با تحلیل ترافیک شبکه حتی می‌توان تراکنش‌ها را به IP مبدأ ربط داد. توصیهٔ رایج ساخت آدرس جدید برای هر تراکنش تنها مقداری ناپیوندپذیری (unlinkability) می‌دهد؛ تکنیک‌های مبتنی بر گراف تراکنش، گراف آدرس و گراف موجودیت (entity graph) و اطلاعات عمومی، کاربران را ردیابی می‌کنند. پارسرهای متن‌باز (مثلاً rusty-blockparser نوشته‌شده با Rust) برای استخراج تراکنش، موجودی و اسکریپت از پایگاه داده بلاک‌چین هستند. راه‌حل‌ها سه دسته‌اند:

1. پروتکل‌های اختلاط (mixing protocols): واسطه یا کیف پول مشترک؛ کاربران سپرده می‌گذارند و واسطه سکه‌های هم‌ارزش دیگران را به مقصد می‌فرستد و پیوند ورودی/خروجی شکسته می‌شود. نمونه: CoinJoin که چند تراکنش را در یک تراکنش بزرگ‌تر مشترک ادغام می‌کند (ورودی‌ها و خروجی‌ها دست‌نخورده) و همهٔ شرکت‌کنندگان آن را امضا می‌کنند.
2. سرویس‌های اختلاط شخص ثالث: اگر متمرکز باشند، سرویس همهٔ ورودی‌ها و خروجی‌ها را می‌داند و حتی ممکن است مدیران سکه‌ها را بدزدند. نمونه‌های مبتنی بر CoinJoin: CoinShuffle (جایگزین غیرمتمرکز بدون نیاز به شخص ثالث مورد اعتماد)، Coinmux، و Darksend در Dash. ضعف CoinJoin: حملهٔ انکار سرویس (DoS) توسط شرکت‌کننده‌ای که متعهد شده امضا کند ولی امضا نمی‌دهد و تراکنش مشترک را متوقف می‌کند.
3. گمنامی ذاتی: ارزهایی که حریم خصوصی در طراحی‌شان است؛ مشهورترین Zcash با اثبات‌های دانش صفر (ZKP) و Monero با امضاهای حلقه‌ای (ring signatures).

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

سکه‌های رنگی (Colored Coins)

روش‌هایی برای نمایش دارایی‌های دیجیتال (smart property) روی بلاک‌چین بیت‌کوین. «رنگی کردن» یک بیت‌کوین یعنی افزودن فراداده به آن؛ سکه همچنان مثل بیت‌کوین کار می‌کند ولی اطلاعاتی دربارهٔ دارایی، محاسبات مرتبط یا داده دلخواه با خود دارد و امکان صدور و ردیابی سکه‌های مشخص فراهم می‌شود. فراداده با opcode به نام OP_RETURN یا در آدرس‌های چندامضایی ثبت می‌شود، می‌تواند رمزنگاری شود و در برخی پیاده‌سازی‌ها روی شبکه‌های تورنت ذخیره می‌شود (یعنی حجم تقریباً نامحدود؛ معمولاً اشیای JSON). قراردادهای هوشمند نیز پشتیبانی می‌شوند؛ مثال: Colu.

دارایی‌ها می‌توانند کالا، گواهی، سهام، اوراق، رأی و غیره باشند. کیف پول عادی بیت‌کوین سکه رنگی را از غیررنگی تشخیص نمی‌دهد، پس کیف پول مخصوص لازم است؛ سرویس Coinprism امکان ساخت چنین کیف پولی و صدور دارایی را می‌دهد و API در coloredcoins.org موجود است. مزیت بزرگ: بدون تغییر پروتکل بیت‌کوین از شبکهٔ امن آن بهره می‌برد. «دارایی‌های هوشمند» با شرایطی مثل اعتبار زمانی، محدودیت انتقال و کارمزد ممکن‌اند و به قراردادهای هوشمند (فصل ۹) پیوند می‌خورند. کاربرد مهم: صدور ابزارهای مالی با کارمزد کم، اثبات مالکیت ریاضی‌وار امن، انتقال سریع بدون واسطه و پرداخت سود سهام فوری.

Counterparty

سرویسی برای ساخت توکن‌های سفارشی و صدور دارایی دیجیتال روی بلاک‌چین بیت‌کوین، با کلاینت و ابزار اختصاصی؛ معماری شامل counterparty server، counter block، counter wallet و armory_utxsvr است. ایده مانند سکه‌های رنگی: جاسازی داده در تراکنش‌های معمولی بیت‌کوین با OP_RETURN که به آن اجماع جاسازی‌شده (embedded consensus) گویند، اما با کتابخانه و ابزار کامل‌تر. ارز آن XCP است که کارمزد اجرای قرارداد هوشمند محسوب می‌شود (قیمت در زمان نگارش حدود ۲٫۷۸ دلار) و با روش PoB ایجاد شد.

Counterparty ساخت قراردادهای هوشمند اتریوم با Solidity و تعامل با بلاک‌چین بیت‌کوین را از طریق BTC Relay ممکن می‌کند: «رله‌کننده‌ها» (گره‌هایی که BTC Relay اجرا می‌کنند) هدر بلاک‌های بیت‌کوین را به قراردادی در اتریوم می‌فرستند که PoW را راستی‌آزمایی می‌کند و بدین‌ترتیب وقوع یک تراکنش بیت‌کوین ثابت می‌شود. این قرارداد مانند کلاینت‌های SPV بیت‌کوین (فصل ۷) هدرها را ذخیره و بررسی می‌کند.

توسعهٔ آلت‌کوین

ایجاد پروژه از نظر کدنویسی ساده است (فورک کد بیت‌کوین یا ارز دیگر؛ معمولاً C++ مثل بیت‌کوین ولی هر زبانی مانند Go یا Rust ممکن است)، اما بخش دشوار جذب سرمایه‌گذار و کاربر است. پارامترهایی که با فورک تغییر می‌کنند:

دو راه ساخت ارز: فورک کد ارز مستقر و اعمال تغییرات در نقاط راهبردی (رایج و آسان‌تر) یا نوشتن از صفر (کم‌طرفدارتر؛ مثال: NEM). فصل چند ارز را بر اساس ماندگاری، ارزش بازار و نوآوری از زوایای نظری، معامله و استخراج بررسی می‌کند.

Namecoin

نخستین فورک کد بیت‌کوین (۲۰۱۱). هدف نه تولید ارز بلکه ارائهٔ نام‌گذاری غیرمتمرکز با ضدسانسور بودن، حریم خصوصی، امنیت و سرعت بیشتر است تا محدودیت‌های DNS سنتی (کندی و کنترل متمرکز) را جبران کند. اولین راه‌حل مثلث Zooko نیز هست (فصل ۱). Namecoin ثبت جفت کلید/مقدار را ممکن می‌کند؛ از کاربردهای مهم: تأیید گواهی TLS به‌صورت غیرمتمرکز. بلاک‌چین و کیف پول جداگانه دارد (کد در namecoin-core روی GitHub).

سه خدمت اصلی: (۱) ذخیره و انتقال امن نام‌ها (کلیدها)؛ (۲) الصاق مقدار تا ۵۲۰ بایت به نام؛ (۳) تولید ارز دیجیتال Namecoin.

ماینینگ ادغامی (Merged mining)

Namecoin برای اولین بار این ایده را معرفی کرد: ماینر یک بلاک Namecoin می‌سازد و هش آن را در بلاک بیت‌کوین قرار می‌دهد (در scriptSig تراکنش coinbase بلاک بیت‌کوین اشاره‌گر هش به بلاک Namecoin می‌آید). ماینر بلاک بیت‌کوین را حل می‌کند و اگر سختی بیت‌کوین را برآورده کند بلاک بیت‌کوین به شبکه می‌پیوندد (هش Namecoin در آنجا نادیده گرفته می‌شود)؛ اگر فقط سختی Namecoin را برآورده کند بلاک در زنجیرهٔ Namecoin ساخته می‌شود. نتیجه: کل توان محاسباتی همزمان از هر دو شبکه محافظت می‌کند.

معامله و دریافت

ارزش بازار حدود ۲۹٫۱ میلیون دلار (مارس ۲۰۱۸)؛ قابل معامله در صرافی‌هایی مثل Cryptonit، Bisq، Evonax و Bter. استخراج انفرادی دیگر سودآور نیست (نمودار سختی)، بنابراین توصیه می‌شود از ماینینگ ادغامی (مثلاً استخر slushpool که ماینینگ بیت‌کوین را همراه Namecoin عرضه می‌کند)، استخر یا خرید در صرافی استفاده شود. راه سریع دیگر تبدیل ارز با سرویسی مثل ShapeShift: انتخاب ارز واریزی (BTC) و دریافتی (NMC)، وارد کردن آدرس Namecoin گیرنده و آدرس بازگشت بیت‌کوین (برای شکست تراکنش)، نمایش فوری نرخ و کارمزد ماینر (نرخ از بازار، کارمزد الگوریتمی)، ارسال BTC به آدرس اعلام‌شده و دریافت پیام «All Done!» پس از چند دقیقه. تأیید تراکنش در کیف پول حدود یک ساعت زمان می‌برد و تا آن موقع نمی‌توان نام‌ها را مدیریت کرد.

ثبت رکورد

نام‌ها رشته‌های حروف کوچک به شکل d/examplename (مطابق RFC1035) و مقدار یک شیء JSON کدشده با UTF-8 حداکثر ۵۲۰ بایت است. نام عمومی می‌تواند رشتهٔ دودویی تا ۲۵۵ بایت باشد. هر رکورد حدود ۲۰۰ روز (۳۶٬۰۰۰ بلاک) معتبر است و بعد باید تمدید شود. Namecoin دامنهٔ سطح بالای .bit را عرضه می‌کند که با حل‌کننده‌های مخصوص Namecoin قابل مرور است. در کیف پول، گزینهٔ Manage Names؛ پس از وارد کردن نام و Submit، تنظیمات (DNS، IP یا هویت) پرسیده می‌شود. مثال کتاب: ثبت masteringblockchain.bit.

Litecoin

فورکی از بیت‌کوین (۲۰۱۱) با Scrypt به‌عنوان PoW (ریشه در Tenebrix). زمان بلاک ۲٫۵ دقیقه (تراکنش‌های سریع‌تر)، بازتنظیم سختی تقریباً هر ۳٫۵ روز، عرضهٔ کل ۸۴ میلیون.

Scrypt: تابع «ترتیبی حافظه‌سخت» (sequentially memory-hard) که در اصل برای مشتق‌سازی کلید از گذرواژه (PBKDF) پیشنهاد شد. ایدهٔ ضد-ASIC: اگر اجرا حافظهٔ زیادی بخواهد، سخت‌افزار سفارشی به سطح VLSI بزرگ‌تری نیاز دارد. مبنا تبادل زمان-حافظه (TMTO) است: کاهش حافظه هزینهٔ محاسباتی را زیاد می‌کند و بالعکس؛ پس مهاجم یا باید حافظهٔ گران بخرد یا الگوریتم کند اجرا می‌شود. پارامترها: passphrase، salt (برای دفاع در برابر حمله‌های دیکشنری/rainbow table)، N (هزینهٔ حافظه/CPU، توان ۲)، P (موازی‌سازی)، R (اندازهٔ بلوک)، dkLen (طول کلید مشتق‌شده)؛ خروجی Kd. ساختار: ورودی ابتدا با PBKDF2 و HMAC-SHA256 پردازش می‌شود، سپس به ROMix با Blockmix و هستهٔ رمز جریانی Salsa20/8 می‌رود تا حافظهٔ بزرگ پر شود، و خروجی دوباره به PBKDF2 می‌رود تا کلید مشتق‌شده تولید شود.

در Litecoin: N=1024، R=1، P=1 و salt برابر ۸۰ بایت تصادفی (هدر بلاک) با خروجی ۲۵۶ بیتی. با این پارامترها ساخت ASIC چندان دشوار نبود: منطق ترتیبی که داده و nonce را می‌گیرد، PBKDF2/HMAC-SHA256 و Salsa20/8 را اجرا می‌کند و دوباره PBKDF2 ؛ اگر هش کمتر از هدف باشد پایان می‌یابد وگرنه nonce افزایش می‌یابد.

معامله و استخراج: ارزش بازار ≈ ۱۰٫۴۵ میلیارد دلار و قیمت ≈ ۱۸۸٫۰۴ دلار (مارس ۲۰۱۸). استخراج با CPU دیگر سودآور نیست؛ مسیر CPU ← GPU ← ASIC (مثلاً Scrypt Miner Wolf از Ehsminer با ≈ ۲ گیگاهش بر ثانیه) طی شده است و حتی با ASIC بهتر است در استخر استخراج شود. کد در GitHub (litecoin-project) و کیف پول در litecoin.org مشابه Bitcoin Core عمل می‌کند.

Primecoin

نخستین ارز با PoW مفید: جست‌وجوی اعداد اول به‌جای SHA-256. سه نوع زنجیرهٔ اول مناسب‌اند: Cunningham نوع اول، Cunningham نوع دوم و bi-twin. سختی با سازوکار ارزیابی پیوسته تنظیم می‌شود؛ زنجیره‌های اول انتخاب شدند چون با بلندتر شدن زنجیره یافتن سخت‌تر می‌شود اما راستی‌آزمایی سریع می‌ماند. برای جلوگیری از استفادهٔ مجدد PoW در بلاک دیگر، گواهی PoW با پیوند زنجیرهٔ اول به هش هدر بلاک و ترکیب هش هدر والد ساخته می‌شود (باید مبدأ زنجیره بر هش هدر بخش‌پذیر باشد و خارج‌قسمت گواهی است). سختی در هر بلاک (نه هر ۲۰۱۶ بلاک) تنظیم می‌شود و تعداد سکه‌ها محدودیت قطعی ندارد و جامعه‌محور است.

ارزش بازار حدود ۱۷٫۵ میلیون دلار (مارس ۲۰۱۸)؛ ایدهٔ نو و جامعهٔ متعهد سهم کوچکی از بازار را حفظ کرده است. راهنمای استخراج: دانلود کیف پول (استخراج بومی در خود کیف پول مثل کلاینت‌های اولیه بیت‌کوین، یا ابری)، همگام‌سازی با شبکه، باز کردن Debug window از منوی Help، وارد کردن دستورهای فعال‌سازی استخراج در Console، و استخراج انفرادی با CPU (چون ارز مبتنی بر CPU است، CPUهای قوی‌تر مناسب‌ترند؛ جایگزین: سرورهای ابری). نویسنده می‌گوید مفهوم ارزش علمی دارد ولی عدم فعالیت در GitHub نشان می‌دهد توسعهٔ فعال متوقف شده است. مرجع: وایت‌پیپر Sunny King (نام مستعار).

Zcash

راه‌اندازی در ۲۸ اکتبر ۲۰۱۶؛ نخستین ارز با ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) برای حریم خصوصی کامل. اثبات‌ها کوتاه و سریع راستی‌آزمایی می‌شوند، اما راه‌اندازی پارامترهای عمومی اولیه (کلید اثبات‌کننده و کلید راستی‌آزمایی) پیچیده است: باید اعداد تصادفی نمونه‌برداری شود که زباله سمی (toxic waste) نام دارد و باید پس از تولید پارامترها نابود شود وگرنه جعل Zcash ممکن است. تیم Zcash برای این منظور یک مراسم باز و پروتکل محاسبهٔ چندجانبه (MPC) طراحی کرد تا پارامترها از مکان‌های مستقل تولید شوند؛ اگر همهٔ شرکت‌کنندگان مصالحه شوند پارامتر نهایی لو می‌رود (یعنی یک فرد صادق کافی است) و شرکت‌کنندگان تجهیزات تولید کلید را به‌طور فیزیکی نابود کردند.

ویژگی‌های ZK-SNARK: completeness (راهبرد قطعی برای اقناع راستی‌آزماینده به درستی ادعا)، soundness (هیچ اثبات‌کننده‌ای نمی‌تواند گزاره نادرست را درست جلوه دهد)، succinctness (پیام‌ها کوچک)، non-interactive (بدون یا با تعامل بسیار کم) و البته دانش صفر (فصل ۴).

طرح DAP (Decentralized Anonymous Payment): پرداخت مستقیم و خصوصی بدون افشای مبدأ، مقصد و مبلغ. دو نوع آدرس: Z address (مبتنی بر ZKP و دارای حریم خصوصی) و T address (مشابه بیت‌کوین، شفاف).

PoW: Equihash (PoW نامتقارن مبتنی بر مسألهٔ تولد تعمیم‌یافته؛ راستی‌آزمایی بسیار کارا، حافظه‌سخت و مقاوم در برابر ASIC). slow start: پاداش بلاک تا بلاک ۲۰٬۰۰۰ تدریجاً زیاد می‌شود تا شبکه مقیاس‌پذیر شود و ماینرهای اولیه آزمایش کنند و توسعه‌دهندگان در صورت لزوم تنظیم کنند؛ کمیابی ناشی از آن قیمت روز اول را حدود ۲۵٬۰۰۰ دلار رساند (بالاتر از ۱۰ بیت‌کوین به ازای هر ZEC و سفارش‌هایی تا ۲٬۵۰۰ BTC). سختی با نسخهٔ کمی تغییریافتهٔ DigiShield تنظیم می‌شود (فرمول بالا؛ هدف ۱۵۰ ثانیه). قیمت ZEC در مارس ۲۰۱۸ حدود ۳۱۱ دلار.

معامله

صرافی‌هایی مثل CryptoGo و Crypto Robot 365.

راهنمای استخراج (CPU روی اوبونتو)

1. نصب پیش‌نیازها با apt-get (ابزارهای build، autoconf، libtool، git، python و غیره).
2. کلون مخزن: git clone https://github.com/zcash/zcash.git.
3. دانلود کلیدهای اثبات و راستی‌آزمایی با ./zcutil/fetch-param.sh (حدود ۹۱۱ مگابایت در ~/.zcash-params/ شامل sprout-proving.key و sprout-verifying.key).
4. ساخت با ./zcutil/build.sh -j$(nproc) که باینری zcashd تولید می‌کند (nproc تعداد هسته‌ها).
5. ساخت zcash.conf در ~/.zcash/ با گزینه‌هایی چون addnode=mainnet.z.cash (اتصال به mainnet)، rpcuser و rpcpassword برای RPC، gen=1 برای فعال‌سازی استخراج، genproclimit برای تعداد پردازنده‌ها و equihashsolver=tromp برای حل‌کنندهٔ سریع‌تر (اختیاری).
6. اجرای ./zcashd --daemon و سپس تعامل با RPC از طریق zcash-cli (شبیه CLI بیت‌کوین)؛ تراکنش‌ها از CLI یا explorer (مثل explorer.zcha.in) قابل مشاهده است.

تولید آدرس: z_getnewaddress برای Z address (آدرس بسیار بلند) و getnewaddress برای T address (شروع با t1)؛ getinfo اطلاعاتی مثل تعداد بلاک، سختی و موجودی نشان می‌دهد.

استخراج با GPU، ابر و استخر

ماینر رسمی GPU وجود نداشت اما توسعه‌دهندگان متن‌باز نمونه‌های کارا ساخته‌اند؛ شرکت Zcash مسابقه‌ای برای ماینرهای CPU/GPU برگزار کرد (تا زمان نگارش برنده‌ای اعلام نشد؛ zcashminers.org). گزینه‌های دیگر: قراردادهای استخراج ابری و ماینینگ در استخر با پروتکل stratum؛ مثلاً استخر Zcash از NiceHash که ماینرها در آن توان هش خود را می‌فروشند. مثال: ساخت nheqminer (CMake روی اوبونتو یا نسخهٔ آمادهٔ ویندوز/لینوکس) و اجرا با پارامترهای محل سرور (-l)، نام کاربری (-u، مثلاً آدرس بیت‌کوین یا T address برای دریافت پرداخت فروش توان هش) و تعداد رشته‌ها (-t). نویسنده نتیجه می‌گیرد Zcash با استفادهٔ نوآورانه از ZKP راه را برای کاربردهای نیازمند حریم خصوصی ذاتی مثل بانکداری، پزشکی و حقوق باز می‌کند.

عرضهٔ اولیهٔ سکه (ICO)

ICO شبیه IPO (عرضهٔ عمومی اولیه سهام) برای تأمین سرمایهٔ یک استارتاپ است، با تفاوت اصلی: IPO تنظیم‌شده و در چارچوب بازار اوراق بهادار است، اما ICO فاقد مقررات و دسته‌بندی مشخص بود. به‌دلیل کلاهبرداری‌های اخیر و نگرانی‌های حمایت از سرمایه‌گذار، پیشنهاد می‌شود ICO را اوراق بهادار شمرد؛ کمیسیون بورس آمریکا (SEC) اشاره کرده همهٔ سکه‌ها، ICOها و دارایی‌های دیجیتال ممکن است مشمول تعریف «اوراق بهادار» شوند، که قوانین مشابهی را اعمال می‌کند. همچنین احراز هویت مشتری (KYC) و مبارزه با پولشویی (AML) توصیه شده و کارشناسان Howey Test را معیار اوراق بهادار بودن می‌دانند.

تفاوت دیگر: سرمایه‌گذاری معمولاً با ارز رمزنگاری‌شده (بیت‌کوین یا اتریوم، گاهی فیات) انجام می‌شود و پاداش به شکل توکن جدید است؛ مثلاً در جمع‌سپاری اتریوم توکن Ether معرفی شد. «توکن سیل» (token sale) و «کراود سیل» نام‌های هم‌ارز‌اند. توکن برای دسترسی به برنامه و دریافت مشوق‌ها استفاده می‌شود و با رشد استفاده، ارزش آن (و سود سرمایه‌گذاران اولیه) بالا می‌رود.

در ۲۰۱۷ ICO به ابزار پیشروی تأمین سرمایه تبدیل شد. نخستین ICO موفق: Ethereum با ۱۸ میلیون دلار (۲۰۱۴)؛ Tezos ۲۳۲ میلیون دلار در چند هفته؛ Filecoin بیش از ۲۵۰ میلیون دلار. ساخت توکن روی اتریوم استاندارد شده (ERC20 که کتاب اشتباهاً «ECR20» هم نوشته) و ICO روی پلتفرم‌هایی مثل NEM و Stellar هم برگزار شده است. استفاده از ERC20 الزامی نیست و می‌توان بلاک‌چین جدید ساخت.

توکن‌های ERC20

ERC20 یک رابط (interface) است که تابع‌های لازم برای توکن را تعریف می‌کند و جزئیات پیاده‌سازی را به توسعه‌دهنده وامی‌گذارد. ERC مخفف Ethereum Request for Comments و معادل BIPهای بیت‌کوین است (تعریف شده در EIP 20). استاندارد خصوصیت‌ها و قواعدی مثل عرضهٔ کل، موجودی هر دارنده، تابع انتقال (transfer) و توابع تأیید/مجوز (approval و allowance) را مشخص می‌کند. استانداردهای دیگر در دست توسعه: ERC223، ERC777 و ERC827 (توسعه‌ای بر ERC20).

جمع‌بندی

فصل نمایی کلی از چشم‌انداز رمزارزها ارائه می‌دهد: از انگیزه‌های پیدایش آلت‌کوین‌ها (رفع محدودیت‌های بیت‌کوین مانند حریم خصوصی، تمرکز استخراج و مصرف انرژی)، تا جایگزین‌های PoW (حافظه‌سخت، هش زنجیره‌ای، اثبات کار مفید، ذخیره‌سازی، PoS و انواع آن، PoA، پازل‌های غیرقابل برون‌سپاری)، الگوریتم‌های بازتنظیم سختی (KGW، DGW، DigiShield، MIDAS) و پروتکل‌های روی بیت‌کوین (Colored Coins، Counterparty و BTC Relay). پارامترهای طراحی یک ارز جدید مرور شد و ارزهای Namecoin (نام‌گذاری و ماینینگ ادغامی)، Litecoin (Scrypt)، Primecoin (اثبات کار مفید) و Zcash (ZK-SNARK و Equihash) با جزئیات معامله و استخراج بررسی شدند. در پایان ICOها و استاندارد توکن ERC20 معرفی شدند. پژوهش‌های بیشتر به‌ویژه در حوزهٔ حریم خصوصی و مقیاس‌پذیری لازم است؛ فصل بعد به قراردادهای هوشمند می‌پردازد.

فصل ۹ — قراردادهای هوشمند (Smart Contracts)

مقدمه

این فصل مفهوم قرارداد هوشمند (Smart Contract) را معرفی می‌کند. ایده تازه نیست، اما با ظهور بلاک‌چین دوباره جان گرفته و امروز یکی از حوزه‌های فعال پژوهش است. انگیزهٔ اصلی صرفه‌جویی هزینه است: به‌ویژه در صنعت خدمات مالی، قراردادهای هوشمند می‌توانند هزینهٔ تراکنش‌ها را کم کنند و قراردادهای پیچیده را ساده‌تر کنند؛ به همین دلیل نهادهای تجاری و دانشگاهی تلاش می‌کنند آن‌ها را صوری‌سازی (formalize) و عملی کنند.

تاریخچه

• Nick Szabo در اواخر دههٔ 1990 در مقاله‌ای با عنوان Formalizing and Securing Relationships on Public Networks این مفهوم را نظریه‌پردازی کرد. حدود بیست سال طول کشید تا با اختراع بیت‌کوین و پیشرفت بلاک‌چین، پتانسیل واقعی آن دیده شود.
• تعریف Szabo: پروتکل تراکنش الکترونیکی که شرایط قرارداد را اجرا می‌کند؛ اهداف آن برآورده‌کردن شرایط رایج قراردادی (شرایط پرداخت، حق وثیقه، محرمانگی و حتی اجبار به اجرا)، کاهش استثناهای عمدی و غیرعمدی، و کم‌کردن نیاز به واسطه‌های مورد اعتماد است. اهداف اقتصادی مرتبط: کاهش زیان ناشی از تقلب، هزینهٔ داوری و اجرا و سایر هزینه‌های تراکنش.
• بیت‌کوین در 2009 این ایده را به شکل محدود پیاده کرد: انتقال ارزش با یک زبان اسکریپت‌نویسی محدود، روی شبکهٔ همتا‌به‌همتا، بین کاربرانی که لزوماً به هم اعتماد ندارند و بدون واسطهٔ معتمد.

تعریف

اجماعی بر سر تعریف استاندارد وجود ندارد. تعریف پیشنهادی نویسنده: قرارداد هوشمند یک برنامهٔ رایانه‌ای امن و متوقف‌نشدنی است که یک توافق را نمایندگی می‌کند و به‌طور خودکار اجرا و اعمال می‌شود. تحلیل اجزای تعریف:

• برنامهٔ رایانه‌ای: به زبانی نوشته می‌شود که ماشین هدف می‌فهمد و منطق کسب‌وکار (business logic) توافق طرفین را در خود دارد.
• اجرای خودکار: با برقراری شرایط معین، بدون دخالت دستی اجرا می‌شود.
• قابل اعمال (enforceable): همهٔ شروط همان‌طور که تعریف شده اجرا می‌شوند، حتی در حضور مهاجمان. «اعمال» در اینجا فقط اجبار حقوقی سنتی نیست؛ قرارداد هوشمند واقعی باید بر اصل «کد همان قانون است» (code is law) تکیه کند، یعنی نیازی به داور یا شخص ثالث نباشد. قرارداد هوشمند خوداجراست، نه صرفاً از طریق دادگاه قابل اجرا. نویسنده می‌پذیرد که این ایده کمی آرمان‌گرایانهٔ آزادی‌خواهانه است ولی با روح قرارداد هوشمند سازگار است.
• امن و متوقف‌نشدنی: باید تحمل‌پذیر خطا باشد و در زمان معقول اجرا شود و حتی اگر شرایط بیرونی نامساعد شد، وضعیت داخلی سالمش را حفظ کند (برخلاف برنامه‌ای معمولی که در محیط غیرعادی ممکن است رفتار دلخواه نشان دهد یا متوقف شود).

نکات تکمیلی:

• برخی پژوهشگران می‌گویند قرارداد هوشمند لازم نیست کاملاً خودکار باشد و «خودکارپذیر» (automatable) کافی است، چون گاهی ورودی انسانی لازم است (مثلاً تأیید پروندهٔ پزشکی توسط پزشک). نویسنده مخالف است: برای «هوشمند» بودن واقعی باید کاملاً خودکار باشد و ورودی‌های انسانی را هم می‌توان با اوراکل (Oracle) خودکار کرد.
• قراردادهای هوشمند معمولاً وضعیت داخلی خود را با مدل ماشین حالت (state machine) مدیریت می‌کنند: وضعیت قرارداد با برقراری شرایط از پیش تعریف‌شده پیش می‌رود.
• مسئلهٔ حقوقی: آیا کد در دادگاه به‌عنوان قرارداد پذیرفته می‌شود؟ دادگاه کد را نمی‌فهمد؛ پس سؤال‌هایی مثل الزام‌آور بودن حقوقی، چگونگی حل اختلاف درون کد و الزامات مقرراتی و انطباق (compliance) هنوز بی‌پاسخ است.
• «هوشمند» نیستند: فقط همان کاری را می‌کنند که برنامه‌ریزی شده؛ و همین خوب است چون خروجی همیشه یکسان (قطعی) است.
• شکاف دنیای واقعی و دنیای بلاک‌چین: زبان طبیعی را قرارداد نمی‌فهمد و کد را دنیای حقوق نمی‌فهمد. راه‌حل‌های پژوهشی: کدی که هم انسان و هم ماشین بتواند بخواند. نمونه‌ای از کارهای انجام‌شده: ترکیب متن حقوقی با اجزای ماشین‌فهم از طریق یک زبان نشانه‌گذاری؛ مثلاً LKIF (Legal Knowledge Interchange Format) که یک طرح XML برای نمایش نظریه‌ها و اثبات‌های حقوقی است و در پروژهٔ ESTRELLA در 2008 توسعه یافت.

قطعیت (Determinism)

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

چهار ویژگی

دو ویژگی اول حداقل لازم‌اند؛ دو ویژگی بعدی در برخی سناریوها شل می‌شوند. مثلاً قرارداد مشتقهٔ مالی شاید نیازی به معنای کامل و توقف‌ناپذیری نداشته باشد، ولی سند مالکیت (title deed) حتماً باید از نظر معنایی کامل باشد و زبانش برای انسان و کامپیوتر قابل فهم. Ian Grigg برای مسئلهٔ تفسیر، قراردادهای ریکاردی را ابداع کرد.

قراردادهای ریکاردی (Ricardian Contracts)

• Ian Grigg آن را در اواخر دههٔ 1990 در مقالهٔ Financial Cryptography in 7 Layers پیشنهاد کرد و ابتدا در سامانهٔ معامله و پرداخت اوراق Ricardo به‌کار رفت.
• ایده: سندی بنویسیم که هم دادگاه بپذیرد و هم نرم‌افزار بفهمد. به چالش «انتشار ارزش روی اینترنت» پاسخ می‌دهد: ناشر (issuer) را شناسایی می‌کند و همهٔ شروط را در سندی ثبت می‌کند که حقوقاً الزام‌آور باشد.
• ویژگی‌های سند ریکاردی: قراردادی که ناشر به دارندگان ارائه می‌کند؛ حقی ارزشمند که دارنده در اختیار دارد و ناشر مدیریت می‌کند؛ خوانا برای انسان؛ خوانا برای برنامه (قابل پارس مانند پایگاه داده)؛ امضای دیجیتال دارد؛ کلیدها و اطلاعات سرور را حمل می‌کند؛ با شناسهٔ یکتا و امن مرتبط است.
• روش عملی: یک سند واحد شامل متن حقوقی و برچسب‌های ماشین‌خوان ساخته می‌شود؛ ناشر آن را با کلید خصوصی امضا می‌کند؛ سند با تابع چکیده‌ساز هش می‌شود و این هش شناسهٔ سند است. این هش در اجرای قرارداد به هر تراکنش پیوند و امضا می‌شود و شاهدی بر قصد طرفین است.
• مدل پاپیونی (bowtie): سمت چپ «دنیای حقوق» (سند حقوقی با برچسب‌های ماشینی) است؛ سند هش می‌شود؛ هش به‌عنوان شناسه در «دنیای حسابداری» (سیستم‌های حسابداری، معاملاتی و اطلاعاتی) سمت راست استفاده می‌شود. ابتدا در تراکنش آغازین (genesis transaction) و بعد در هر تراکنش، که پیوندی امن بین قرارداد نوشته‌شده و همهٔ تراکنش‌های حسابداری برقرار می‌کند.

تفاوت با قرارداد هوشمند

• قرارداد هوشمند فقط بر اجرا تمرکز دارد و سند قراردادی ندارد؛ قرارداد ریکاردی بر غنای معنایی و تولید سند با متن حقوقی تمرکز دارد.
• معناشناسی دو نوع است: عملیاتی (operational) که اجرا، درستی و ایمنی را تعریف می‌کند و نمادین/دلالتی (denotational) که معنای واقعی قرارداد در دنیای حقیقی را بیان می‌کند. برخی پژوهشگران «کد قرارداد هوشمند» را از «قرارداد حقوقی هوشمند» جدا می‌کنند که هر دو معناشناسی را دربر می‌گیرد؛ نویسنده ترجیح می‌دهد قرارداد هوشمند را موجودیتی مستقل ببیند که هم متن حقوقی و هم منطق کسب‌وکار را کدگذاری می‌کند.
• منطق شرطی ساده در بیت‌کوین کاملاً به اجرا گرایش دارد؛ قرارداد ریکاردی بیشتر برای تولید سند انسان‌خوان با بخش‌های ماشین‌فهم است. Grigg در مقالهٔ On the intersection of Ricardian and smart contracts نشان می‌دهد غنای معنایی و کارایی اجرایی دو محور متعامدند؛ قرارداد هوشمند ایده‌آل هر دو را با هم دارد.
• قرارداد ریکاردی را می‌توان تاپل سه‌تایی دید: Prose (متن حقوقی به زبان طبیعی)، code (برنامهٔ معادل ماشینی متن) و parameters (پارامترهایی که بخش‌های مربوط متن را به کد معادل وصل می‌کنند).
• پیاده‌سازی‌ها: CommonAccord، OpenBazaar، OpenAssets و Askemos.

قالب‌های قرارداد هوشمند (Smart Contract Templates)

• بیشتر کاربردهای فعلی در صنعت مالی است چون بلاک‌چین زودتر در آنجا کاربرد یافت و علاقهٔ پژوهشی برانگیخت.
• Clack و همکاران (2016) در مقالهٔ Smart Contract Templates: Foundations, design landscape and research directions قالب‌های استاندارد را پیشنهاد دادند که چارچوبی برای قراردادهای حقوقی ابزارهای مالی فراهم کند، و ساخت زبان‌های دامنه‌محور (DSL) را هم توصیه کردند. زبانی به نام CLACK (Common Language for Augmented Contract Knowledge) پیشنهاد شده که قرار است غنی باشد: از پشتیبانی متن حقوقی تا اجرا روی چند پلتفرم و توابع رمزنگاری.
• مقالهٔ بعدی Smart Contract Templates: essential requirements and design options بررسی می‌کند چگونه متن حقوقی با زبان نشانه‌گذاری به کد پیوند بخورد و قراردادهای حقوقی هوشمند چگونه ایجاد، قالب‌بندی، اجرا و برای ذخیره و انتقال سریال‌سازی شوند. کار در جریان است.
• DSLها در مالی سابقه دارند: بیمه، مشتقات انرژی، استراتژی‌های معاملاتی (فهرست در dslfin.org).
• DSL در برابر GPL: DSL ویژگی‌های اندک و بهینه برای یک حوزه دارد و برای ساخت برنامه‌های عمومی بزرگ استفاده نمی‌شود. مثال‌های قرارداد هوشمند: Solidity (همراه اتریوم) و Vyper (جدیدتر، برای اتریوم).
• ایدهٔ گسترش: DSL گرافیکی یا پلتفرم مدل‌سازی قرارداد که کارشناس حوزه (نه برنامه‌نویس؛ مثلاً معامله‌گر خط مقدم) روی بوم گرافیکی معنا و اجرای قرارداد را ترسیم کند، ابتدا شبیه‌سازی شود و سپس از همان سامانه روی بلاک‌چین مستقر شود. نمونهٔ مشابه: محصول Tibco StreamBase برای سامانه‌های معاملاتی پرتکرار. پیشنهاد می‌شود پژوهش روی DSLهای سطح بالا با رابط گرافیکی ادامه یابد تا مثلاً یک وکیل بتواند قرارداد هوشمند طراحی کند.

اوراکل‌ها (Oracles)

محدودیت: قرارداد هوشمند نمی‌تواند به داده‌های بیرون از بلاک‌چین دسترسی بگیرد، مثلاً قیمت سهام برای آزادسازی سود سهام. اوراکل واسطی است که داده را از منبع خارجی به قرارداد می‌رساند.

• انواع داده: گزارش آب‌وهوا، اخبار دنیای واقعی، رویدادهای شرکتی، داده از دستگاه‌های اینترنت اشیا (IoT).
• اوراکل‌ها نهادهای معتمدند که از کانال امن داده می‌فرستند و می‌توانند داده را امضای دیجیتال کنند تا اصالت منبع ثابت شود. قرارداد می‌تواند مشترک اوراکل شود و داده را بکشد (pull) یا اوراکل آن را بفرستد (push). اوراکل نباید بتواند داده را دستکاری کند؛ این اطمینان را می‌توان با طرح‌های notary تأمین کرد.
• مسئلهٔ اعتماد: چرا باید به شخص ثالث برای کیفیت و اصالت داده اعتماد کنیم؟ در دنیای مالی دقت داده حیاتی است. پذیرش داده از یک نهاد بزرگ و معتبر ممکن است قابل قبول باشد، اما مشکل تمرکز باقی می‌ماند. این‌ها اوراکل‌های استاندارد/ساده هستند (مثلاً سازمان هواشناسی یا سامانهٔ فرودگاه برای تأخیر پرواز).
• راه دیگر: دریافت داده از چند منبع (حتی عموم مردمی که آگاه‌اند) و تجمیع آن؛ هرچه منابع بیشتری یک اطلاعات را بدهند، احتمال درستی بیشتر است.
• اوراکل‌های غیرمتمرکز: بر مبنای سازوکار توزیع‌شده یا حتی دریافت داده از بلاک‌چین دیگری که اجماع دارد؛ مثلاً یک نهاد با بلاک‌چین خصوصی خود خوراک داده‌اش را از طریق اوراکل برای بلاک‌چین‌های دیگر منتشر کند.
• اوراکل‌های سخت‌افزاری: داده از دستگاه‌های فیزیکی (تله‌متری، IoT). نیازمند دستگاه ضد دستکاری با شواهد رمزنگاری (عدم انکار و تمامیت) و مکانیزمی که دستگاه را در صورت دستکاری از کار بیندازد.
• روش نوشتن داده: بسته به بلاک‌چین فرق دارد. مثلاً در بیت‌کوین اوراکل داده را در تراکنشی مشخص می‌نویسد و قرارداد آن تراکنش را رصد و داده را می‌خواند.
• خدمات اوراکل: Oraclize (oraclize.it)، Reality Keys و smartcontract.com (داده خارجی و پرداخت از طریق قرارداد).
• برای اثبات اصالت داده‌ای که اوراکل از منبع خارجی می‌گیرد می‌توان از TLSnotary استفاده کرد که اثبات ارتباط بین منبع داده و اوراکل تولید می‌کند.

اوراکل‌های هوشمند (Smart Oracles)

ایدهٔ Ripple Labs (پروژهٔ Codius): موجودیتی مانند اوراکل ولی با قابلیت اجرای کد قرارداد. Codius از Google Native Client، یک محیط sandbox برای اجرای کد native x86 غیرقابل‌اعتماد، استفاده می‌کند.

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

• الزامی نیست روی بلاک‌چین مستقر شوند ولی به دلیل اجماع توزیع‌شده و غیرمتمرکز بلاک‌چین معقول است. اتریوم به‌صورت بومی از توسعه و استقرار قرارداد پشتیبانی می‌کند و قراردادها معمولاً بخشی از برنامه‌ای بزرگ‌تر مانند DAO (سازمان خودمختار غیرمتمرکز) هستند.
• در بیت‌کوین: قفل‌های زمانی مثل فیلد nLocktime و عملگرهای اسکریپت CHECKLOCKTIMEVERIFY (CLTV) و CHECKSEQUENCEVERIFY تراکنش را تا زمان مشخص یا تعداد بلاک مشخص قفل می‌کنند؛ مثلاً «بعد از سه ماه N بیت‌کوین به طرف X بپرداز». بسیار محدود، اما نمونهٔ ساده‌ای از قرارداد هوشمند است. نمونهٔ دیگر: آدرسی که هر کس ثابت کند برخورد هش (hash collision) را یافته می‌تواند خرج کند؛ مسابقه‌ای که در انجمن Bitcointalk برای هش‌ها برگزار شد و بیت‌کوین جایزهٔ کسی بود که برخورد پیدا کند؛ آزادسازی مشروط یک قرارداد هوشمند ابتدایی است.
• پلتفرم‌های دیگر با پشتیبانی قرارداد هوشمند: Monax، Lisk، Counterparty، Stellar، Hyperledger Fabric، Corda و Axoni Core.
• نیاز حیاتی قطعیت است: کد هر کجا اجرا شود باید همان نتیجه را بدهد؛ این به معنی بی‌نیازی از رفع باگ نیست و راستی‌آزمایی (validation/verification) قراردادها حوزهٔ پژوهشی فعالی است که در فصل 18 (Scalability and Other Challenges) بررسی می‌شود.
• زبان‌ها: Solidity (روی ماشین مجازی اتریوم EVM)؛ Lisk از جاوااسکریپت پشتیبانی می‌کند؛ Hyperledger Fabric از Go، Java و JavaScript.

ماجرای DAO

• DAO یکی از بزرگ‌ترین پروژه‌های تأمین مالی جمعی بود که در آوریل 2016 آغاز شد: مجموعه‌ای از قراردادهای هوشمند به‌عنوان بستر سرمایه‌گذاری.
• در ژوئن 2016 به‌دلیل باگ کد، معادل حدود 50 میلیون دلار به حسابی دیگر منتقل شد.
• نویسنده تأکید می‌کند «هک» دقیق نیست: قرارداد همان کاری را کرد که از آن خواسته شده بود؛ رفتاری ناخواسته که برنامه‌نویسان پیش‌بینی نکرده بودند.
• پیامد: هارد فورک در اتریوم برای بازیابی. این رویداد نشان می‌دهد باور به «کد همان قانون است» و قراردادهای متوقف‌نشدنی را باید با تردید دید، چون پیاده‌سازی این مفاهیم هنوز بالغ نیست؛ بنیاد اتریوم توانست اجرای DAO را متوقف و تغییر دهد که هرچند به دلایل موجه بود، با روح غیرمتمرکز بودن و «کد قانون است» در تضاد است.
• در مقابل، مقاومت در برابر این فورک و ماینرهایی که روی زنجیرهٔ اصلی ماندند به ایجاد Ethereum Classic انجامید: زنجیرهٔ اصلی بدون فورک که در آن کد هنوز قانون است.
• درس‌ها: لزوم آزمون رسمی و کامل قراردادها، لزوم توسعهٔ زبان صوری برای توسعه و راستی‌آزمایی، و ضرورت یک چارچوب استاندارد برای مشکلات متعدد کشف‌شده در زبان توسعهٔ قراردادها. نمونهٔ ابزار: سرویس securify.ch برای راستی‌آزمایی صوری قراردادها.

جمع‌بندی

• قرارداد هوشمند برنامه‌ای است که شروط توافق را خودکار اجرا و اعمال می‌کند؛ ایدهٔ Szabo در دههٔ 1990 با بلاک‌چین عملی شد. دو ویژگی ضروری: اجرای خودکار و قابلیت اعمال؛ دو ویژگی دیگر: معنای سالم و امن/متوقف‌نشدنی.
• قطعیت شرط لازم اجماع است.
• قرارداد ریکاردی (Grigg) سندی حقوقی و ماشین‌خوان با شناسهٔ هش است؛ بر معنا تمرکز دارد، در حالی که قرارداد هوشمند بر اجراست؛ ایدهٔ ایده‌آل ترکیب هر دو است.
• قالب‌ها و DSLها (CLACK، Solidity، Vyper و DSLهای گرافیکی) مسیرهای پژوهشی فعال‌اند.
• اوراکل‌ها (ساده، چندمنبعی، غیرمتمرکز، سخت‌افزاری و هوشمند) پل بین دنیای بیرون و قرارداد هستند، اما مسئلهٔ اعتماد را وارد می‌کنند.
• بیت‌کوین قراردادهای ابتدایی (timelock) دارد و اتریوم بستر بومی قراردادهاست؛ ماجرای DAO و پیدایش Ethereum Classic اهمیت آزمون و راستی‌آزمایی صوری را نشان می‌دهد.
• فصل بعد اتریوم را معرفی می‌کند.

فصل ۱۰ — مقدمه‌ای بر اتریوم (Ethereum 101)

مقدمه

این فصل مقدمه‌ای بر بلاک‌چین اتریوم (Ethereum) است: مفاهیم بنیادین و نظری و اجزا، پروتکل‌ها و الگوریتم‌های مرتبط. (فصل بعد، Further Ethereum، به کیف پول، ماینینگ، گره‌ها، چالش‌های امنیت و مقیاس‌پذیری و بازار می‌پردازد.) اتریوم را Vitalik Buterin در نوامبر 2013 مفهوم‌پردازی کرد. ایدهٔ کلیدی آن یک زبان تورینگ‌کامل (Turing-complete) است که امکان ساخت برنامه‌های دلخواه (قراردادهای هوشمند) و برنامه‌های غیرمتمرکز را می‌دهد؛ در مقابل بیت‌کوین که زبان اسکریپتش عمداً محدود است و فقط عملیات لازم را اجازه می‌دهد.

نسخه‌های اتریوم

این فصل بر Byzantium (آخرین نسخهٔ زمان نگارش) تمرکز دارد.

مقالهٔ زرد (Yellow Paper)

مشخصات رسمی پروتکل اتریوم را Dr. Gavin Wood (بنیان‌گذار اتریوم و Parity) در «مقالهٔ زرد» نوشته است و هر کس می‌تواند با پیروی از آن یک کلاینت اتریوم پیاده کند. خواندنش برای کسانی که با نمادهای ریاضی آشنا نیستند دشوار است. کتاب جدولی از نمادهای ریاضی مقاله و معنایشان آورده (مثلاً «تعریف می‌شود به‌عنوان»، عضویت، برای همه، وجود دارد، اجتماع، طول، کف و سقف، XOR و …)، و از جمله نمادهای مهم: سیگما برای وضعیت جهانی (world state)، میو برای وضعیت ماشین (machine state) و اپسیلون برای تابع انتقال وضعیت اتریوم و نمادی برای تابع انتقال سطح بلاک و تابع ایجاد قرارداد.

بلاک‌چین اتریوم

اتریوم مانند هر بلاک‌چین را می‌توان یک ماشین حالت مبتنی بر تراکنش (transaction-based state machine) دید (تعریف مقالهٔ زرد). یک وضعیت آغازین (genesis) با اجرای تدریجی تراکنش‌ها به وضعیت نهایی تبدیل می‌شود و این وضعیت نهایی به‌عنوان نسخهٔ بدون‌اختلاف پذیرفته می‌شود. مثال شکل کتاب: انتقال دو اتر از یک آدرس به آدرس دیگر که وضعیت قبل را به وضعیت بعد می‌برد. ماینینگ در این انتقال نقش محوری دارد. وضعیت روی شبکه به‌صورت world state (وضعیت سراسری بلاک‌چین) ذخیره می‌شود.

اتریوم از دید کاربر (نمای کلی)

سناریو: انتقال وجه از Bashir به Irshad با دو کلاینت (کیف پول Jaxx روی iOS):

1. گیرنده (Irshad) درخواست پول می‌دهد، مثلاً با ارسال آدرس اتریومش به‌صورت QR code (از طریق ایمیل، پیام و …)، یا فرستنده خودش تصمیم می‌گیرد پول بفرستد.
2. فرستنده QR را اسکن می‌کند یا آدرس را دستی وارد می‌کند، مبلغ را می‌نویسد و تراکنش را تأیید می‌کند.
3. تراکنش در نرم‌افزار کیف پول ساخته، توسط فرستنده امضای دیجیتال می‌شود (اثبات مالکیت اتر) و در شبکه پخش می‌شود.
4. گره‌های ماینر آن را برای راستی‌آزمایی و گنجاندن در بلاک برمی‌دارند؛ تا اینجا هنوز تأییدنشده است.
5. پس از قرارگرفتن در بلاک، فرایند اثبات کار (PoW) آغاز می‌شود.
6. وقتی ماینری با هش‌کردن مکرر بلاک و nonce جدید پاسخ مسئله را یافت، بلاک فوراً پخش می‌شود و بقیهٔ گره‌ها بلاک و PoW را تأیید می‌کنند.
7. در صورت موفقیت همهٔ بررسی‌ها بلاک به زنجیره اضافه و پاداش ماینرها پرداخت می‌شود.
8. اتر در کیف پول Irshad نمایش داده می‌شود.

تراکنش با یک هش تراکنش (TxHash) شناسایی می‌شود (در مثال کتاب مقداری که با 0xc63dce…009e شروع می‌شود) و جزئیاتش در کاوشگر بلاک Etherscan دیده می‌شود. این هش شناسهٔ یکتا برای ردیابی تراکنش در شبکه است و در فصل بعد برای نشان‌دادن ساخت، پردازش و ذخیرهٔ آن به‌کار می‌رود.

شبکهٔ اتریوم

شبکه‌ای همتا‌به‌همتا که گره‌ها برای نگهداری بلاک‌چین و مشارکت در اجماع در آن شرکت می‌کنند. سه نوع:

• Mainnet: شبکهٔ زندهٔ فعلی؛ نسخهٔ Byzantium (Metropolis) با chain ID برابر 1. کاوشگر: etherscan.io.
• Testnet: عمدتاً Ropsten، شبکهٔ آزمون برای آزمودن قراردادها و DApps پیش از استقرار روی شبکهٔ اصلی و برای آزمایش و پژوهش. شبکه‌های آزمون کوچک‌تر و ویژه مثل Kovan و Rinkeby برای آزمودن نسخهٔ Byzantium ساخته شدند و تغییراتشان در Ropsten هم اعمال شده است.
• Private net: شبکهٔ خصوصی با ایجاد بلاک آغازین جدید؛ معمولاً در دفتر کل خصوصی که گروهی خصوصی بلاک‌چین خود را به‌عنوان بلاک‌چین مجوزدار (permissioned) راه می‌اندازد.

نحوهٔ اتصال به testnet و راه‌اندازی private net در فصل 12 آمده است.

اجزای اکوسیستم اتریوم

پشته (stack) شامل: بلاک‌چین اتریوم روی شبکهٔ همتا‌به‌همتا؛ کلاینت اتریوم (معمولاً Geth) که روی گره‌ها اجرا می‌شود، بلاک‌چین را دانلود و محلی ذخیره و همگام می‌کند و کارهایی مثل ماینینگ و مدیریت حساب را فراهم می‌کند؛ و کتابخانهٔ web3.js که از طریق رابط RPC با Geth تعامل دارد.

عناصر سطح بالای بلاک‌چین اتریوم: کلیدها و آدرس‌ها، حساب‌ها، تراکنش‌ها و پیام‌ها، ارز اتر/توکن‌ها، EVM، قراردادهای هوشمند.

کلیدها و آدرس‌ها

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

1. کلید خصوصی به‌صورت تصادفی انتخاب می‌شود: عدد صحیح مثبت 256 بیتی در بازهٔ مجاز منحنی secp256k1 (از 1 تا n-1).
2. کلید عمومی با تابع ECDSA از کلید خصوصی مشتق می‌شود.
3. آدرس (کد 20 بایتی برای شناسایی حساب) برابر 160 بیت راست (سمت کم‌ارزش) هش Keccak کلید عمومی است.

کتاب مثال عددی از کلید خصوصی (64 رقم هگز)، کلید عمومی (128 رقم هگز) و آدرس به شکل 0x77b4…6f32 نشان می‌دهد.

حساب‌ها (Accounts)

حساب‌ها از بلوک‌های بنیادی اتریوم‌اند. اتریوم ماشین حالت تراکنش‌محور است و وضعیت در اثر تعامل حساب‌ها و اجرای تراکنش‌ها ساخته یا به‌روز می‌شود. تابع انتقال وضعیت اتریوم چنین عمل می‌کند:

1. اعتبار تراکنش بررسی می‌شود: نحو (syntax)، اعتبار امضا و nonce.
2. کارمزد محاسبه می‌شود، فرستنده از روی امضا تعیین می‌شود، موجودی فرستنده بررسی و کم می‌شود و nonce یک واحد افزایش می‌یابد؛ اگر موجودی کافی نباشد خطا برمی‌گردد.
3. به‌اندازهٔ کافی اتر (قیمت gas) برای پوشش هزینهٔ تراکنش برداشته می‌شود (به‌ازای هر بایت متناسب با اندازهٔ تراکنش). در این مرحله انتقال ارزش از حساب فرستنده به گیرنده انجام می‌شود. اگر حساب مقصد وجود نداشته باشد خودکار ساخته می‌شود؛ اگر مقصد قرارداد باشد کد آن اجرا می‌شود و بسته به gas موجود یا کامل اجرا می‌شود یا تا جایی که gas تمام شود.
4. اگر تراکنش به‌علت کمبود موجودی یا gas شکست بخورد همهٔ تغییرات وضعیت برگردانده می‌شود (rollback) به‌جز پرداخت کارمزد که به ماینر می‌رسد.
5. در پایان، باقی‌ماندهٔ کارمزد (در صورت وجود) به فرستنده برمی‌گردد، کارمزد به ماینرها داده می‌شود و وضعیت حاصل روی بلاک‌چین ذخیره می‌شود.

انواع حساب

نکات: کد حساب قرارداد به‌دلیل تورینگ‌کامل بودن اتریوم می‌تواند هر سطحی از پیچیدگی داشته باشد و توسط EVM روی هر گره ماینر اجرا می‌شود. قرارداد وضعیت دائمی دارد و می‌تواند قراردادهای دیگر را فراخواند. پیش‌بینی می‌شود در نسخهٔ Serenity تمایز بین EOA و CA برداشته شود.

تراکنش‌ها و پیام‌ها

تراکنش در اتریوم بستهٔ داده‌ای امضاشده با کلید خصوصی است که دستورهایی دارد که نتیجه‌اش یا پیام‌فراخوانی (message call) است یا ایجاد قرارداد. بر اساس خروجی دو نوع‌اند:

• تراکنش message call: پیامی از یک حساب به حساب دیگر می‌فرستد.
• تراکنش ایجاد قرارداد: حسابی جدید با کد وابسته می‌سازد.

فیلدهای مشترک

Wei کوچک‌ترین واحد اتر است.

جزئیات امضا:

• V: یک بایت (27 یا 28) به‌عنوان recovery ID که برای بازیابی کلید عمومی از امضا به‌کار می‌رود (در secp256k1 مقدار 0 یا 1 و در اتریوم با افست 27).
• R: مختصات x نقطه‌ای روی منحنی که از ضرب یک عدد تصادفی در مولد منحنی به دست می‌آید؛ 32 بایت؛ بین 0 و n.
• S: از ضرب R در کلید خصوصی، افزودن هش پیام و تقسیم بر عدد تصادفی؛ 32 بایت.
• امضا با تابع ECDSASIGN(Message, PrivateKey) = (V, R, S) ساخته می‌شود.

تراکنش‌ها در trie تراکنش (درخت Merkle-Patricia اصلاح‌شده) قرار می‌گیرند و ریشهٔ آن با Keccak-256 هش و در سرآیند بلاک گذاشته می‌شود. تراکنش‌ها یا در استخر تراکنش منتظر تأییدند یا در بلاک‌اند. ماینر از تراکنش‌های با بیشترین کارمزد شروع می‌کند و یکی‌یکی اجرا می‌کند تا به سقف gas برسد یا تراکنشی نماند. سپس بلاک تکراراً هش می‌شود تا nonce‌ای بیابد که هش کمتر از هدف دشواری باشد؛ بلاک موفق فوراً پخش می‌شود. تفاوت با بیت‌کوین: الگوریتم PoW اتریوم Ethash است که مقاوم در برابر ASIC است و پیدا کردن nonce به حافظهٔ زیاد نیاز دارد.

تراکنش ایجاد قرارداد

پارامترهای لازم: فرستنده، آغازگر اصلی تراکنش، gas موجود، قیمت gas، endowment (اتر تخصیص‌یافته)، آرایه‌بایت دلخواه، کد EVM اولیه و عمق فعلی پشتهٔ message call/ایجاد قرارداد.

• آدرس قرارداد 160 بیتی است؛ طبق مقالهٔ زرد، 160 بیت راست هش Keccak از کدگذاری RLP ساختاری که فقط فرستنده و nonce را دارد.
• در آغاز: nonce حساب صفر، موجودی برابر value ارسالی، storage خالی، code hash برابر هش Keccak-256 رشتهٔ تهی.
• حساب با اجرای کد مقداردهی اولیه ساخته می‌شود. در صورت هر استثنا مثل Out Of Gas (OOG) وضعیت تغییر نمی‌کند؛ در موفقیت، حساب پس از پرداخت gas ساخته می‌شود.
• از Homestead به بعد نتیجه یا قرارداد جدید با موجودی خود است یا هیچ قراردادی ساخته نمی‌شود و ارزشی منتقل نمی‌شود؛ برخلاف قبل از Homestead که قرارداد حتی با شکست استقرار کد به‌علت OOG ساخته می‌شد.

تراکنش message call

پارامترها: فرستنده، آغازگر تراکنش، گیرنده، حسابی که کدش اجرا می‌شود (معمولاً همان گیرنده)، gas موجود، value، قیمت gas، آرایه‌بایت ورودی و عمق فعلی پشته. message call باعث انتقال وضعیت می‌شود و داده خروجی هم تولید می‌کند (در اجرای تراکنش بی‌استفاده است، ولی وقتی کد VM آن را فرابخواند استفاده می‌شود). اگر مقصد کد EVM داشته باشد ماشین مجازی با دریافت پیام شروع به کار می‌کند.

پیام‌ها (Messages)

بستهٔ داده و value (اتر) بین دو حساب. یا از قرارداد (شیء خودمختار) یا از بازیگر خارجی (EOA) در قالب تراکنش امضاشده می‌آید. پیام‌ها فقط در محیط اجرا وجود دارند و ذخیره نمی‌شوند؛ برخلاف تراکنش که از موجودیت‌های بیرون از محیط اتریوم می‌آید، پیام را قراردادها تولید می‌کنند. اجزا: فرستنده، گیرنده، مقدار Wei، فیلد اختیاری داده، و سقف gas (startgas). پیام هنگام اجرای opcodeهای CALL یا DELEGATECALL تولید می‌شود.

Calls

call چیزی روی بلاک‌چین پخش نمی‌کند؛ فراخوانی محلی تابع قرارداد روی گره است، شبیه dry run یا شبیه‌سازی، فقط‌خواندنی و بدون gas و بدون تغییر وضعیت چون هرگز استخراج نمی‌شود. با تراکنش message call اشتباه گرفته نشود؛ call همان را در حالت شبیه‌سازی اجرا می‌کند و در web3.js در دسترس است.

اعتبارسنجی و اجرای تراکنش

بررسی‌های اولیه: تراکنش خوش‌ساخت و RLP بدون بایت اضافه؛ امضای معتبر؛ nonce برابر nonce فعلی حساب فرستنده؛ gas limit کمتر از gas مصرفی نباشد؛ موجودی فرستنده برای هزینهٔ اجرا کافی باشد.

زیرحالت تراکنش (Transaction Substate)

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

• مجموعهٔ suicide/self-destruct: حساب‌هایی که پس از تراکنش حذف می‌شوند.
• سری لاگ (log series): نقاط بازبینی اندیس‌گذاری‌شده برای مانیتورینگ و اطلاع‌رسانی فراخوانی قرارداد به موجودیت‌های بیرون (مثل frontend)؛ مثل تریگری که با فراخوانی تابع یا رویداد مشخص اجرا می‌شود؛ می‌تواند ذخیره‌سازی ارزان‌تر هم باشد (رویدادها در فصل 14).
• موجودی بازپرداخت (refund balance): بازپرداخت‌ها فوراً اعمال نمی‌شوند و بخشی از هزینهٔ کل اجرا را جبران می‌کنند.
• حساب‌های touched: حساب‌های لمس‌شده که تهی‌هایشان در پایان تراکنش حذف می‌شود.

ذخیرهٔ وضعیت در بلاک‌چین اتریوم

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

وضعیت جهانی (World State)

نگاشت بین آدرس‌های 20 بایتی و وضعیت حساب‌ها که با RLP (Recursive Length Prefix) سریال‌سازی می‌شود. RLP طرح کدگذاری ویژهٔ اتریوم است برای سریال‌سازی داده دودویی جهت ذخیره، انتقال شبکه و نگهداری وضعیت در درخت Patricia؛ ورودی رشته یا فهرست است و بایت خام تولید می‌کند. هدف اصلی‌اش کدگذاری ساختار است نه خود داده.

وضعیت حساب (Account State)

چهار فیلد:

• Nonce: تعداد تراکنش‌های ارسالی از آدرس؛ در حساب قرارداد تعداد قراردادهای ساخته‌شده توسط آن.
• Balance: تعداد Wei.
• Storage root: ریشهٔ درخت Merkle Patricia که محتوای storage حساب را کدگذاری می‌کند.
• Code hash: هش تغییرناپذیر کد قرارداد؛ برای حساب عادی هش Keccak-256 رشتهٔ تهی.

رابطه: درخت storage حساب (نگاشت هش Keccak-256 کلیدهای 256 بیتی به مقادیر 256 بیتی کدگذاری‌شده با RLP) ← ساختار حساب ← world state trie (نگاشت آدرس به وضعیت حساب) ← ریشهٔ آن با Keccak-256 هش می‌شود و به‌عنوان state root در سرآیند بلاک می‌آید.

رسیدهای تراکنش (Transaction Receipts)

برای ثبت نتیجهٔ اجرای هر تراکنش؛ همهٔ رسیدها در یک trie با کلید اندیس ذخیره می‌شوند و هش ریشهٔ آن در سرآیند بلاک به‌عنوان receipts root می‌آید. چهار عنصر:

• وضعیت پس از تراکنش (post-transaction state)؛
• Gas used: کل gas مصرفی در بلاک حاوی رسید، بلافاصله پس از اجرا؛
• مجموعهٔ لاگ‌ها: شامل آدرس logger، فهرست topicها (ساختارهای 32 بایتی) و داده؛
• فیلتر بلوم (bloom filter): از اطلاعات لاگ‌ها ساخته می‌شود و به‌صورت logs bloom 256 بایتی در سرآیند بلاک قرار می‌گیرد.

با Byzantium فیلد افزوده‌ای هم موفقیت (1) یا شکست (0) تراکنش را برمی‌گرداند (EIP-658).

اتر (Ether)؛ ETH و ETC

اتر ارز بومی اتریوم (ETH) است که به‌عنوان انگیزهٔ ماینرها و برای پرداخت هزینهٔ اجرای قراردادها روی EVM به‌کار می‌رود؛ اتر برای خرید gas (سوخت رمزنگاری) لازم است. پس از هک DAO هارد فورک پیشنهاد شد و اکنون دو بلاک‌چین وجود دارد: Ethereum Classic (ارز ETC، نسخهٔ اصلی بدون فورک با جامعهٔ اختصاصی) و ETH (نسخهٔ فورک‌شده که فعال‌ترین و رسمی‌ترین است و محور این فصل).

برای هر محاسبهٔ EVM کارمزد گرفته می‌شود (جدول کامل در فصل 11).

ماشین مجازی اتریوم (EVM)

• ماشین اجرای ساده و مبتنی بر پشته که بایت‌کد را اجرا می‌کند تا وضعیت سیستم را تغییر دهد. اندازهٔ کلمه 256 بیت؛ پشته حداکثر 1024 عنصر، به‌صورت LIFO؛ big-endian. کلمهٔ 256 بیتی برای محاسبات Keccak-256 و ECC مناسب است.
• تورینگ‌کامل اما محدود با gas؛ حلقه‌های بی‌نهایت و حملات انکار سرویس به‌خاطر نیاز gas ممکن نیست. استثناها (کمبود gas، دستور نامعتبر) ماشین را فوراً متوقف و خطا را به عامل اجراکننده برمی‌گردانند.
• ایزوله و sandbox: کد به شبکه یا فایل‌سیستم دسترسی ندارد؛ این امنیت و اجرای قطعی می‌دهد و اجرای کد غیرقابل‌اعتماد (هر کس) را ممکن می‌کند.
• دو نوع فضای ذخیره: memory (آرایه‌بایت، شبیه RAM، پس از پایان اجرا پاک می‌شود) و storage (پایدار روی بلاک‌چین، key-value با کلید و مقدار 32 بایتی، مانند دیسک). حافظه نامحدود ولی محدود به هزینهٔ gas. کد برنامه در ROM مجازی (فقط‌خواندنی) است که با دستور CODECOPY به حافظهٔ اصلی کپی می‌شود. در آغاز همهٔ storage و memory صفر است.
• عملیات: کد از حافظه خوانده می‌شود با ارجاع به program counter و دستورها گام‌به‌گام اجرا می‌شوند؛ پشته و PC با هر دستور به‌روز می‌شوند.
• بهینه‌سازی: پژوهش روی WebAssembly (WASM) (از Google، Mozilla و Microsoft و استاندارد W3C) و eWASM؛ هدف EVM 2.1 اجرای native opcodeها روی CPU. زبان JULIA هم می‌تواند به backendهایی مثل EVM و eWASM کامپایل شود.

محیط اجرا (Execution Environment)

تاپل ده‌عنصری که عامل اجرا (مثلاً تراکنش) فراهم می‌کند: وضعیت سیستم، gas باقی‌مانده، آدرس مالک کد در حال اجرا، آدرس فرستندهٔ تراکنش، آدرس مبدأ اجرا (ممکن است با فرستنده فرق کند)، قیمت gas، داده ورودی، آدرس آغازکنندهٔ اجرا، value، کد اجرایی (آرایه‌بایت)، سرآیند بلاک فعلی، تعداد CALL/CREATE در حال اجرا و مجوز تغییر وضعیت. خروجی اجرا: وضعیت حاصل، gas باقی‌مانده، مجموعهٔ self-destruct، سری لاگ و بازپرداخت‌های gas.

وضعیت ماشین (Machine State)

پس از هر چرخهٔ اجرا به‌روز می‌شود و شامل: gas موجود، program counter، محتوای پشته و تعداد کلمات فعال حافظه (و محتوای حافظه). استثناهایی که اجرا را متوقف می‌کنند: gas ناکافی، دستور نامعتبر، آیتم ناکافی در پشته، مقصد نامعتبر jump، اندازهٔ پشتهٔ بیش از 1024.

تابع تکرارکننده (Iterator Function)

تابعی که یک چرخهٔ ماشین حالت را اجرا می‌کند: دستور بعدی را از بایت‌کد می‌گیرد، آیتم‌ها را PUSH/POP می‌کند، gas را مطابق هزینهٔ opcode کم می‌کند و PC را زیاد می‌کند. توقف عادی با opcodeهای STOP، SUICIDE یا RETURN رخ می‌دهد.

قراردادهای هوشمند و قراردادهای بومی (Precompiled)

قراردادهای هوشمند روی EVM اجرا می‌شوند و با زبان‌های مختلف نوشته می‌شوند (فصل‌های 13 و 14). علاوه بر آن‌ها قراردادهای از پیش‌کامپایل‌شده (native/precompiled) هستند: توابعی که درون کلاینت (Parity، Geth) کد شده‌اند و برای وظایف محاسباتی سنگین به‌صورت بومی روی گره محلی اجرا می‌شوند، نه قرارداد Solidity به معنای معمول. در Byzantium هشت تا وجود دارد:

ممکن است در آینده این قراردادها به افزونه‌های بومی و opcodeهای EVM تبدیل شوند.

جمع‌بندی

• اتریوم (Vitalik Buterin، 2013) پلتفرمی با زبان تورینگ‌کامل برای قراردادهای هوشمند و DApps است؛ نسخه‌ها: Olympic، Frontier، Homestead، Byzantium (اکتبر 2017) و بعدها Constantinople و Serenity (PoS). مشخصات رسمی در مقالهٔ زرد Gavin Wood است.
• اتریوم ماشین حالت تراکنش‌محور است: world state نگاشت آدرس به حساب است و حساب‌ها دو نوع‌اند (EOA و CA) با چهار فیلد nonce، balance، storage root و code hash.
• تراکنش‌ها امضاشده‌اند و دو دسته‌اند (ایجاد قرارداد و message call)؛ فیلدها شامل nonce، gas price، gas limit، to، value، (v,r,s) و init/data؛ پیام‌ها فقط درون اجرا وجود دارند. وضعیت، تراکنش‌ها و رسیدها هر کدام ریشهٔ trie جداگانه در سرآیند بلاک دارند و RLP و Merkle Patricia ابزار کدگذاری و ذخیره‌اند.
• اتر (ETH) با واحدهای Wei تا Ether، سوخت (gas) را می‌خرد؛ فورک پس از DAO باعث ETH/ETC شد.
• EVM ماشین پشته‌ای 256 بیتی، ایزوله و محدود به gas است با memory و storage؛ هشت قرارداد از پیش‌کامپایل‌شده توابع سنگین رمزنگاری را فراهم می‌کنند.
• فصل بعد به زبان‌های برنامه‌نویسی، ساختار بلاک، ماینینگ، کلاینت‌ها و … می‌پردازد.

فصل ۱۱ — ادامهٔ اتریوم (Further Ethereum)

مقدمه

این فصل ادامهٔ فصل ۱۰ (Ethereum 101) است و بقیهٔ اجزای اکوسیستم اتریوم را از زاویهٔ نظری و عملی پوشش می‌دهد. سرفصل‌های اصلی به همین ترتیب‌اند:

• زبان‌های برنامه‌نویسی قراردادهای هوشمند و مجموعهٔ دستورهای ماشین مجازی (opcodeهای EVM)؛
• بلاک‌ها و بلاک‌چین اتریوم: ساختار بلاک، بلاک جنسیس، اعتبارسنجی، دشواری، گس و فورک‌ها؛
• گره‌ها و ماینرها: اجماع، الگوریتم Ethash، ماینینگ با CPU/GPU، دستگاه‌های ماینینگ و استخرها؛
• کیف پول‌ها و نرم‌افزارهای کلاینت (Geth، Parity، Mist و …)؛
• APIها (Web3) و برنامه‌های غیرمتمرکز؛
• پروتکل‌های پشتیبان Whisper و Swarm؛
• چالش‌های مقیاس‌پذیری و امنیت، و در پایان معامله و سرمایه‌گذاری روی اتر.

زبان‌های برنامه‌نویسی

کد قرارداد هوشمند اتریوم به یک زبان سطح بالا نوشته و سپس به بایت‌کد (bytecode) قابل‌فهم برای EVM کامپایل می‌شود. زبان‌های مطرح‌شده:

LLL و Serpent دیگر از سوی جامعه پشتیبانی نمی‌شوند و کاربردشان تقریباً از بین رفته است؛ بنابراین کتاب تمرکز را روی Solidity می‌گذارد (آموزش کامل آن در فصل ۱۳).

مثال کتاب یک قرارداد بسیار ساده (Test1) با pragma solidity ^0.4.0 است که یک متغیر uint x=2 و تابعی به نام addition1 دارد که ورودی را با ۲ جمع می‌کند. خروجی کامپایل آن به دو شکل نشان داده می‌شود: بایت‌کد زمان اجرا (runtime bytecode) به‌صورت رشتهٔ هگز خام، و فهرست خوانای opcodeها (مثل PUSH1 0x60 PUSH1 0x40 MSTORE ...) که نشان می‌دهد هر خط سطح بالا به چه دنباله‌ای از دستورهای پشته‌ای تبدیل می‌شود.

Opcodeها و معنای آن‌ها

EVM ماشینی پشته‌محور است و دستورهایش برحسب عملکرد در دسته‌هایی قرار می‌گیرند. جدول‌های کتاب برای هر opcode پنج چیز را می‌دهند: نام نمادین (mnemonic)، مقدار هگز، تعداد آیتم‌هایی که از پشته برداشته می‌شود (POP)، تعداد آیتم‌هایی که روی پشته گذاشته می‌شود (PUSH)، هزینهٔ گس و توضیح. مرور دسته‌ها:

عملیات حسابی (۰x00 تا ۰x0b)

تمام محاسبات EVM به‌پیمانهٔ ۲^۲۵۶ است. شامل ADD (گس ۳)، MUL (۵)، SUB (۳)، DIV، SDIV، MOD، SMOD (۵)، ADDMOD و MULMOD (۸، با سه ورودی)، EXP (۱۰) و SIGNEXTEND (۵). STOP (۰x00) به‌رغم این‌که حسابی نیست، به‌خاطر محدودهٔ مقدارش در همین دسته آمده و اجرا را متوقف می‌کند.

عملیات منطقی (۰x10 تا ۰x1a)

مقایسه‌ها و عملیات بیتی.

عملیات رمزنگاری

فقط یک opcode به نام SHA3؛ نکته این‌که این همان استاندارد SHA-3 مؤسسهٔ NIST نیست و پیاده‌سازی اصلی Keccak است. هزینه: ۳۰ گس پایه به‌علاوهٔ ۶ گس به‌ازای هر «کلمه» (word) ورودی، یعنی 30 + 6 × (تعداد کلمات ورودی).

اطلاعات محیطی (۱۳ دستور)

برای دریافت اطلاعات آدرس، محیط اجرا و کپی داده‌ها: ADDRESS (آدرس حساب در حال اجرا)، BALANCE (موجودی حساب؛ گس ۲۰)، ORIGIN (فرستندهٔ اصلی تراکنش)، CALLER (حسابی که اجرا را آغاز کرده)، CALLVALUE (مقدار اتر ارسالی همراه فراخوانی)، CALLDATALOAD/CALLDATASIZE/CALLDATACOPY (خواندن و کپی داده‌های ورودی پیام)، CODESIZE/CODECOPY، GASPRICE، EXTCODESIZE/EXTCODECOPY (کد حساب دیگر؛ گس ۲۰)، و RETURNDATASIZE/RETURNDATACOPY (داده‌های بازگشتی از فراخوانی قبلی).

اطلاعات بلاک (۰x40 تا ۰x45)

BLOCKHASH (هش یکی از ۲۵۶ بلاک اخیر)، COINBASE (دریافت‌کنندهٔ پاداش)، TIMESTAMP، NUMBER، DIFFICULTY و GASLIMIT.

پشته، حافظه، ذخیره‌سازی و جریان اجرا

POP، MLOAD/MSTORE/MSTORE8 (حافظهٔ موقت، گس ۳)، SLOAD (خواندن از storage دائمی، گس ۵۰)، SSTORE (نوشتن در storage)، JUMP (گس ۸) و JUMPI (پرش شرطی، گس ۱۰)، PC، MSIZE، GAS، و JUMPDEST که مقصد معتبر پرش را علامت می‌زند.

دستورهای PUSH، DUP، SWAP

• PUSH1 تا PUSH32 (۰x60 تا ۰x7f): ۳۲ دستور برای گذاشتن ۱ تا ۳۲ بایت (از کد برنامه) روی پشته، گس ۳.
• DUP1 تا DUP16 (۰x80 تا ۰x8f): کپی‌کردن N‌امین آیتم پشته (مثلاً DUP1 یک آیتم برمی‌دارد و دو آیتم می‌گذارد).
• SWAP1 تا SWAP16 (۰x90 تا ۰x9f): جابه‌جایی آیتم بالای پشته با N‌امین آیتم.

عملیات لاگ‌گذاری

LOG0 تا LOG4 برای افزودن رکورد لاگ با ۰ تا ۴ موضوع (topic)؛ هزینهٔ پایه از ۳۷۵ گس شروع می‌شود و با هر topic ۳۷۵ گس بیشتر می‌شود (۳۷۵، ۷۵۰، ۱۱۲۵، ۱۵۰۰، ۱۸۷۵).

عملیات سیستمی (۹ دستور)

در مجموع، در نسخهٔ Byzantium حدود ۱۲۹ opcode در EVM وجود دارد.

بلاک‌ها و بلاک‌چین

هر بلاک اتریوم سه بخش دارد: سرایند بلاک (block header)، فهرست تراکنش‌ها، و فهرست سرایند اُمرها (ommers / uncles)، یعنی بلاک‌های کهنه.

سرایند بلاک

مهم‌ترین و پیچیده‌ترین بخش بلاک. فیلدها:

• Parent hash: هش Keccak 256 بیتی سرایند بلاک والد؛
• Ommers hash: هش فهرست سرایند اُمرهای گنجانده‌شده؛
• Beneficiary: آدرس ۱۶۰ بیتی دریافت‌کنندهٔ پاداش ماینینگ؛
• State root: هش ریشهٔ درخت وضعیت (state trie) پس از اعمال همهٔ تراکنش‌ها؛
• Transactions root: هش ریشهٔ درخت تراکنش‌های بلاک؛
• Receipts root: هش ریشهٔ درخت رسیدها (هر تراکنش پس از پردازش یک رسید با اطلاعات پس‌تراکنشی تولید می‌کند)؛
• Logs bloom: فیلتر بلوم ساخته‌شده از آدرس لاگ‌گذار و topicهای لاگ هر رسید؛
• Difficulty: دشواری بلاک؛
• Number: تعداد بلاک‌های قبلی؛ جنسیس شمارهٔ صفر است؛
• Gas limit: سقف مصرف گس در بلاک؛
• Gas used: مجموع گس مصرف‌شده توسط تراکنش‌های بلاک؛
• Timestamp: زمان یونیکس شروع بلاک؛
• Extra data: داده‌ٔ دلخواه تا ۳۲ بایت؛
• Mixhash و Nonce (۶۴ بیتی): در کنار هم گواه صرف توان محاسباتی کافی (اثبات کار) برای ساخت بلاک‌اند.

بلاک جنسیس

بلاک جنسیس به‌خاطر نحوهٔ ساخت و داده‌هایش کمی با بلاک‌های عادی فرق دارد و ۱۵ مورد دارد. نمونهٔ واقعی از Etherscan: زمان 30 ژوئیهٔ ۲۰۱۵؛ هش والد همه‌صفر؛ دشواری ۱۷٬۱۷۹٬۸۶۹٬۱۸۴؛ اندازهٔ ۵۴۰ بایت؛ nonce برابر 0x42؛ گس مصرفی ۰؛ پاداش ۵ اتر؛ سقف گس ۵٬۰۰۰ و ماینر صفر.

اعتبارسنجی بلاک

بلاک معتبر است اگر: (۱) اُمرهایش واقعاً اُمر باشند و اثبات کارشان معتبر باشد؛ (۲) بلاک والد وجود داشته و معتبر باشد؛ (۳) زمان‌سنج معتبر باشد، یعنی از زمان والد بزرگ‌تر و حداکثر ۱۵ دقیقه جلوتر از اکنون باشد. شکست در هر یک به رد بلاک می‌انجامد.

نهایی‌سازی بلاک (Block finalization)

ماینرها چهار گام را اجرا می‌کنند:

1. اعتبارسنجی اُمرها: معتبر بودن سرایند و رعایت حداکثر عمق ۶ بلاک؛ حداکثر ۲ اُمر در هر بلاک؛
2. اعتبارسنجی تراکنش‌ها: برابری گس مصرفی بلاک با گس تجمعی تراکنش‌ها؛
3. اعمال پاداش‌ها: برای ماینر بلاک (در Byzantium از ۵ به ۳ اتر کاهش یافت)، برای اُمرهای گنجانده‌شده ۷/۸ پاداش بلاک، و برای ماینری که اُمر را درج می‌کند ۱/۳۲ پاداش؛
4. اعتبارسنجی وضعیت و nonce: راستی‌آزمایی وضعیت و nonce بلاک (در ماینینگ، محاسبهٔ آن‌ها).

دشواری بلاک و Ice Age

دشواری برای حفظ زمان تقریباً ثابت تولید بلاک تنظیم می‌شود: اگر فاصلهٔ دو بلاک کم باشد دشواری بالا می‌رود و اگر زیاد باشد پایین می‌آید. فرمول Homestead چنین است: دشواری والد + (دشواری والد تقسیم صحیح بر ۲۰۴۸) × max(1 − (اختلاف زمان // 10), −99) + جمله‌ای نمایی 2^((شماره بلاک // 100000) − 2).

تفسیر: اگر فاصلهٔ دو بلاک کمتر از ۱۰ ثانیه باشد دشواری زیاد می‌شود؛ بین ۱۰ تا ۱۹ ثانیه ثابت می‌ماند؛ ۲۰ ثانیه یا بیشتر باعث کاهش متناسب می‌شود. جملهٔ آخر همان بمب دشواری یا عصر یخبندان (Difficulty Time Bomb / Ice Age) است که با هر ۱۰۰٬۰۰۰ بلاک نمایی دشوارتر می‌شود تا ماینینگ PoW سرانجام عملاً ناممکن شود و ماینرها به اثبات سهام (PoS) به‌نام Casper مهاجرت کنند. این بمب با پیشنهاد EIP-649 حدود یک و نیم سال به تعویق افتاد؛ در Byzantium پاداش از ۵ به ۳ اتر رسید (آمادگی برای PoS در Serenity) و فرمول دشواری عوض شد تا اُمرها را هم لحاظ کند: ضریب تنظیم = max((۲ اگر والد اُمر داشت وگرنه ۱) − (اختلاف زمان // ۹), −۹۹).

گس (Gas)

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

• هزینهٔ تراکنش = gasUsed × gasPrice؛ gasPrice را آغازگر به‌عنوان مشوق برای ماینر تعیین می‌کند. کارمزد کم ممکن است باعث شود تراکنش هرگز انتخاب نشود.
• این مقدار تخمین است؛ اجرای واقعی ممکن است گس کمتر یا بیشتر مصرف کند.
• اگر گس تمام شود، خطای out-of-gas رخ می‌دهد: همهٔ تغییرات برگردانده می‌شود اما تراکنش در بلاک می‌ماند و بازپرداختی نیست. اگر اجرا موفق و گس باقی باشد، باقی‌مانده بازگردانده می‌شود.
• مثال: SHA-3 ‏۳۰ گس هزینه دارد؛ با قیمت گس ۲۵ GWei (برابر ۰٫۰۰۰۰۰۰۰۲۵ اتر) هزینه ۰٫۰۰۰۰۰۰۷۵ اتر می‌شود. سایت ethgasstation.info قیمت‌های روز گس را نشان می‌دهد.
• جدول هزینه (fee schedule): گس در سه حالت پیش از اجرا دریافت می‌شود: محاسبهٔ یک عملیات، ساخت قرارداد یا فراخوانی پیام، و افزایش مصرف حافظه.

فورک‌ها در بلاک‌چین

• فورک سخت (hard fork) در ارتقاهای بزرگ: Frontier ← Homestead در بلاک ۱٬۱۵۰٬۰۰۰ و Byzantium (بخش اول Metropolis) در بلاک ۴٬۳۷۰٬۰۰۰.
• فورک ناخواسته در ۲۴ نوامبر ۲۰۱۶ (بلاک ۲٬۶۸۶٬۳۵۱) به‌علت باگ در سازوکار journaling کلاینت Geth در مدیریت حذف حساب‌های خالی هنگام خطای out-of-gas؛ Parity این مشکل را نداشت و در نتیجه شبکه موقتاً بین دو کلاینت دو شاخه شد. با Geth 1.5.3 رفع شد.
• فورک ناشی از هک DAO (فصل ۹).

گره‌ها و ماینرها

شبکهٔ اتریوم انواع گره دارد: گره‌های صرفاً کیف پول، کلاینت‌های سبک، کلاینت‌های کامل و گره‌های ماینینگ. ماینینگ فرایند انتخاب بلاک‌های جدید از طریق سازوکار اجماع و افزودن آن‌ها به زنجیره است و ماینرها برای اعتبارسنجی تراکنش‌ها اتر دریافت می‌کنند. وظایف نظری یک ماینر: گوش دادن به تراکنش‌های پخش‌شده و انتخاب آن‌ها؛ تشخیص اُمرها و درج‌شان؛ به‌روزرسانی موجودی خود با پاداش؛ و در نهایت محاسبهٔ وضعیت معتبر و نهایی‌سازی بلاک. روش فعلی PoW و شبیه بیت‌کوین است، اما قرار است با انتشار Serenity (نسخهٔ نهایی اتریوم؛ بدون تاریخ مشخص) با PoS جایگزین شود. Casper پروتکلی مبتنی بر سپردهٔ اقتصادی است: گره‌ها باید پیش از تولید بلاک سپرده بگذارند (bonding) و اعتبارسنج‌های سپرده‌گذار (bonded validators) نامیده می‌شوند.

سازوکار اجماع: GHOST

اجماع اتریوم بر پروتکل GHOST (Greedy Heaviest Observed Subtree) استوار است که Zohar و Sompolinsky در دسامبر ۲۰۱۳ معرفی کردند. اتریوم نسخهٔ ساده‌ای از آن را به کار می‌برد: زنجیرهٔ مرجع، زنجیره‌ای است که بیشترین کار محاسباتی در آن صرف شده. GHOST برای مقابله با مشکل بلاک‌های کهنه/یتیم ناشی از زمان کوتاه تولید بلاک طراحی شد: در محاسبهٔ «سنگین‌ترین» زنجیره، بلاک‌های کهنه (اُمرها) هم لحاظ می‌شوند. در بیت‌کوین قانون طولانی‌ترین زنجیره حاکم است؛ در اتریوم اُمرها که کار PoW واقعی انجام داده‌اند ولی وارد زنجیرهٔ اصلی نشده‌اند نیز پاداش و وزن می‌گیرند، لذا زنجیره «سنگین‌ترین» است نه فقط طولانی‌ترین.

Ethash

Ethash الگوریتم PoW اتریوم است (در اصل Dagger-Hashimoto پیشنهاد شد). ایدهٔ اصلی مانند بیتی‌کوین: یافتن nonceای که پس از الحاق به سرایند و هش‌شدن، عددی کوچک‌تر از آستانهٔ دشواری بدهد. در ابتدا ماینینگ با CPU و یک GPU سودآور بود؛ اکنون یا استخر یا مزارع بزرگ GPU لازم است.

• Ethash حافظه‌سخت (memory-hard) است تا ساخت ASIC را بی‌فایده و ماینینگ را غیرمتمرکزتر نگه دارد؛ بخش‌هایی از یک منبع ثابت به نام DAG (گراف جهت‌دار بدون دور) بر اساس nonce و سرایند انتخاب می‌شود.
• DAG حدود ۲ گیگابایت است و هر ۳۰٬۰۰۰ بلاک (حدود ۵٫۲ روز، یک epoch) تغییر می‌کند؛ ماینینگ فقط پس از تولید کامل DAG در اولین راه‌اندازی شروع می‌شود.
• پاداش فعلی ۳ اتر برای یافتن nonce معتبر، به‌علاوهٔ کارمزد گس بلاک و پاداش اضافی برای درج اُمرها (حداکثر دو اُمر، هرکدام ۷/۸ پاداش عادی). برای رسیدن به زمان بلاک حدود ۱۲ ثانیه، دشواری در هر بلاک تنظیم می‌شود. درآمد متناسب با نرخ هش (hash rate) ماینر است و ماشین‌حساب‌های ماینینگ (مثل Etherscan) سودآوری را برآورد می‌کنند.
• شرط لازم: گره باید کاملاً با شبکهٔ اصلی همگام شده باشد.

ماینینگ با CPU

در شبکهٔ اصلی سودآور نیست اما روی testnet و شبکهٔ خصوصی برای آزمایش ماینینگ و استقرار قرارداد مفید است (فصل ۱۲). با Geth: geth --mine --minerthreads <n>؛ یا با کنسول: geth attach و سپس miner.start(4) (چهار رشته؛ خروجی True در صورت موفقیت) و miner.stop() برای توقف.

ماینینگ با GPU

ابتدا geth --rpc اجرا و بلاک‌چین کامل دانلود می‌شود، سپس ethminer -G (ماینر مستقل که در حالت farm هم به استخرها می‌پیوندد). نیاز به کارت AMD یا NVIDIA و OpenCL SDK مناسب (CUDA برای NVIDIA). در نبود GPU مناسب، ethminer خطا می‌دهد.

بنچمارک

ethminer -M -C برای بنچمارک CPU و ethminer -M -G برای GPU؛ انتخاب دستگاه با --opencl-device 1. چون پیاده‌سازی بر OpenCL است، GPUهای AMD معمولاً سریع‌تر از NVIDIA عمل می‌کنند. به‌دلیل نیاز حافظهٔ بالای DAG، FPGA و ASIC برتری چشمگیری ندارند؛ این عمدی است.

دستگاه‌های ماینینگ (Mining rigs)

با افزایش دشواری، ریگ‌هایی با چند GPU (معمولاً حدود پنج کارت) ساخته شد. اجزای معمول:

• مادربرد ویژه با اسلات‌های PCI-E x1/x16 (مثل BIOSTAR Hi-Fi یا ASRock H81)؛
• SSD با حدود ۲۵۰ گیگابایت فضای آزاد برای بلاک‌چین؛
• GPU (مثلاً Sapphire AMD Radeon R9 380 با ۴ گیگ)؛ بنچمارک‌ها در miningbenchmark.net؛
• سیستم‌عامل: Ubuntu یا توزیع ویژهٔ EthOS به‌جای ویندوز، برای پایداری و سبک‌تر بودن؛
• نرم‌افزار: Ethminer و Geth، به‌علاوهٔ ابزار پایش از راه دور، و تهویه/خنک‌سازی مناسب با هشدار دمای بالا؛
• منبع تغذیه (PSU) با توان حدود ۱٬۰۰۰ وات.

استخرهای ماینینگ

استخرهای آنلاین زیادی وجود دارند و ethminer با دستوری مانند ethminer -C -F <آدرس استخر>?miner=...@<آدرس ولت>@<نام کارگر> به آن‌ها وصل می‌شود؛ خروجی با پیام «Getting work package» شروع می‌شود. دستور اتصال هر استخر در مستندات خودش آمده است.

کیف پول‌ها و نرم‌افزار کلاینت

اتریوم در حال توسعهٔ سریع است و اجزای فراوانی دارد. کلاینت‌ها:

نصب

روی Ubuntu، Geth با افزودن مخزن ppa:ethereum/ethereum و apt-get install ethereum نصب می‌شود و با دستور geth از پیش‌فرض‌ها برای اتصال به شبکهٔ اصلی استفاده می‌کند. Eth با apt-get install cpp-ethereum نصب می‌شود.

مرورگر Mist و کیف پول‌ها

Mist مرورگر DApp با رابط گرافیکی برای مدیریت حساب‌ها و قراردادها است. در اولین اجرا Geth را در پس‌زمینه راه می‌اندازد و همگام می‌شود (از چند ساعت تا چند روز؛ روی testnet یعنی Ropsten سریع‌تر). مهم: Mist خودش کیف پول نیست؛ Ethereum Wallet یک DApp همراه آن است. کیف پول به تعریف کتاب برنامه‌ای عمومی است که کلید خصوصی را نگه می‌دارد و با پرس‌وجو از بلاک‌چین موجودی آدرس‌ها را محاسبه می‌کند و می‌تواند قرارداد هم مستقر کند. ساخت حساب جدید در Mist از منوی ACCOUNTS یا گزینهٔ ADD ACCOUNT انجام می‌شود و نیاز به تعیین گذرواژه دارد.

کیف پول‌های دیگر: MyEtherWallet (متن‌باز، JavaScript، اجرا در مرورگر کاربر)؛ Icebox از ConsenSys (ذخیره‌سازی سرد در مرورگر که امنیتش به آفلاین بودن رایانه بستگی دارد)؛ و Jaxx (موبایل).

مدیریت حساب با Geth

• ساخت حساب: geth account new (درخواست گذرواژه دو بار؛ گذرواژه را نباید فراموش کرد) و چاپ آدرس؛
• فهرست حساب‌ها: geth account list که برای هر حساب مسیر فایل keystore (نام فایل شامل زمان UTC و آدرس) را نشان می‌دهد؛
• کنسول JavaScript: geth attach به یک نمونهٔ در حال اجرا (حتی Parity) وصل می‌شود؛ دستور personal.newAccount() حساب می‌سازد و eth.accounts آدرس‌ها را فهرست می‌کند.

شارژ حساب با بیت‌کوین

در Mist گزینهٔ fund account از سرویس ShapeShift (رابط «Shifty») برای تبدیل بیت‌کوین یا سایر ارزها (حتی فیات) به اتر استفاده می‌کند و پس از تکمیل مبادله، اتر در حساب ظاهر می‌شود.

نصب و استفادهٔ Parity

• نصب روی Ubuntu/Mac با bash <(curl https://get.parity.io -Lk)؛ نصب‌کننده پیشنهاد نصب Netstats را هم می‌دهد (دیمنی که آمار را به ethstats.net می‌فرستد؛ آن سایت اطلاعاتی مثل آخرین بلاک، زمان بلاک، دشواری، قیمت گس و فهرست گره‌ها با نام، نوع، تأخیر، وضعیت ماینینگ، همتاها، تراکنش‌های معلق و تعداد اُمرها نشان می‌دهد).
• اجرا با parity -j؛ برای سازگاری با Geth تا Mist روی Parity کار کند: parity --geth؛ در این حالت UI غیرفعال است و با parity --geth --force-ui فعال می‌شود.
• parity ui رابط وب برای مدیریت حساب‌ها، دفترچهٔ آدرس، DAppها، قراردادها، وضعیت و امضا را باز می‌کند.
• ساخت حساب: parity account new (هشدار: گذرواژه بازیافتنی نیست).

APIها، ابزارها و DAppها

• Web3 JavaScript API: شیء web3 با متدهایی برای مدیریت بلاک‌چین، دیباگ، حساب‌ها، Whisper، ذخیره‌سازی و عملیات شبکه. جزئیات در فصل ۱۲.
• DAppها و DAOها: مهم‌ترین آن‌ها The DAO بود (پلتفرم غیرمتمرکز جمع‌آوری و توزیع سرمایه) که به‌خاطر ضعف کد سوءاستفاده شد و برای بازیابی وجوه به هارد فورک انجامید. Augur بازار پیش‌بینی غیرمتمرکز است. فهرست DAppها در stateofthedapps.com.
• ابزارهای توسعه: Truffle، MetaMask، Ganache، TestRPC و غیره (فصل ۱۳).

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

برای یک اکوسیستم کاملاً غیرمتمرکز، علاوه بر لایهٔ قرارداد (محاسبه) باید لایه‌های ذخیره‌سازی و پیام‌رسانی نیز غیرمتمرکز شوند.

Whisper

پیام‌رسانی نظیربه‌نظیر غیرمتمرکز برای ارتباط DAppها با یکدیگر. ویژگی‌ها: رمزنگاری داده و مسیریابی پیام‌ها؛ استفاده از پروتکل سیمی DEVp2p؛ مناسب انتقال داده‌های کوچک و سناریوهای غیر‌بلادرنگ؛ ارتباط غیرقابل ردیابی و مقاوم در برابر سانسور؛ پیام‌ها زودگذرند و TTL دارند. دلیل وجودش: استفاده از بلاک‌چین برای پیام‌رسانی گران است و برای پیام‌ها نیازی به اجماع نیست. در Geth با گزینهٔ --shh فعال می‌شود.

Swarm

شبکهٔ ذخیره‌سازی توزیع‌شدهٔ نظیربه‌نظیر که فایل‌ها را بر اساس هش محتوایشان آدرس‌دهی می‌کند (بر خلاف سرویس‌های متمرکز). لایهٔ پایهٔ بومی پشتهٔ Web 3 اتریوم است، با DEVp2p یکپارچه می‌شود، در برابر DDoS مقاوم و تحمل‌پذیر خطا طراحی شده و پروتکل bzz را به‌کار می‌برد (همانند shh برای Whisper).

تصویر کلی: اتریوم کامپیوتر غیرمتمرکز (وضعیت و محاسبه)، Whisper ارتباط غیرمتمرکز و Swarm ذخیره‌سازی غیرمتمرکز است. این در امتداد بحث فصل ۲ دربارهٔ تمرکززدایی کل اکوسیستم و نه فقط هستهٔ محاسباتی است.

مقیاس‌پذیری، امنیت و سایر چالش‌ها

مقیاس‌پذیری مسئلهٔ بنیادین هر بلاک‌چین است؛ امنیت نیز اهمیت حیاتی دارد و حریم خصوصی و محرمانگی به‌ویژه در بخش مالی مانع پذیرش بوده‌اند. تحقیقات گسترده‌ای در جریان است و بحث تفصیلی در فصل ۱۸ آمده است.

معامله و سرمایه‌گذاری

ارزش بازار اتریوم در زمان نگارش کتاب (مارس ۲۰۱۸) حدود ۶۷٫۸ میلیارد دلار و هر اتر حدود ۶۹۰ دلار بود (نمودار تاریخی از Etherscan). اتر را می‌توان از صرافی‌هایی مانند Kraken و Coinbase با ارز فیات (کارت اعتباری) یا ارز مجازی دیگر مثل بیت‌کوین خرید، یا ماین کرد؛ سرویس‌هایی مانند ShapeShift تبدیل ارزها را انجام می‌دهند. (این بخش توصیهٔ سرمایه‌گذاری نیست؛ فقط راهنمای دسترسی است.)

جمع‌بندی

• Solidity زبان غالب قراردادهای هوشمند است و کد به بایت‌کد و opcodeهای پشته‌ای EVM (حدود ۱۲۹ دستور در Byzantium) با هزینهٔ گس مشخص تبدیل می‌شود.
• هر بلاک شامل سرایند (با ریشه‌های state/transactions/receipts، bloom، دشواری، گس، nonce)، تراکنش‌ها و اُمرها است؛ اعتبارسنجی و نهایی‌سازی چهارگامی بلاک، پاداش (۳ اتر پس از Byzantium) و اُمرها را تنظیم می‌کند.
• اجماع بر GHOST و PoW از نوع حافظه‌سخت Ethash (DAG حدود ۲ گیگ، epoch ۳۰٬۰۰۰ بلاک، زمان بلاک حدود ۱۲ ثانیه) استوار است؛ بمب دشواری و Casper مسیر گذار به PoS را تعیین می‌کنند.
• گس هم از حلقهٔ بی‌نهایت جلوگیری می‌کند و هم مشوق ماینرهاست؛ فورک‌ها (Homestead، Byzantium، باگ Geth و DAO) نمونه‌هایی از تکامل و آسیب‌پذیری شبکه‌اند.
• کلاینت‌های Geth و Parity، مرورگر Mist و کیف پول‌هایی مانند MyEtherWallet و Jaxx ابزار عملی تعامل با شبکه‌اند؛ ماینینگ با CPU/GPU، ریگ‌ها و استخرها نیز مرور شد.
• Whisper (پیام‌رسانی) و Swarm (ذخیره‌سازی) در کنار اتریوم، تصویر یک وب غیرمتمرکز کامل را می‌سازند؛ فصل بعد به محیط توسعه و استقرار قرارداد می‌پردازد.

فصل ۱۲ — محیط توسعهٔ اتریوم (Ethereum Development Environment)

مقدمه و هدف فصل

این فصل نخستین فصل عملی دربارهٔ اتریوم است و مفاهیم نظری فصل‌های قبل را با مثال‌های کاربردی همراه می‌کند. محور فصل راه‌اندازی محیط توسعه و استفاده از ابزارهای بومی اتریوم برای ساخت و استقرار قرارداد هوشمند است. دو گزینهٔ اصلی بررسی می‌شود:

• شبکهٔ آزمایشی (testnet) عمومی به نام Ropsten، که توسعه‌دهندگان برای آزمودن قراردادها و پیشنهادهای مرتبط با بلاک‌چین از آن استفاده می‌کنند؛
• شبکهٔ خصوصی (private net)، یعنی بلاک‌چینی کاملاً مستقل که می‌تواند میان چند نهاد شرکت‌کننده به‌عنوان دفتر کل توزیع‌شده مشترک عمل کند و برای توسعه و تست قراردادها هم به کار می‌رود.

کلاینت اتریوم در مثال‌ها Geth (پیاده‌سازی Go) است. کلاینت‌های دیگری مانند Parity هم هست (در فصل ۱۱ معرفی شد) اما Geth کلاینت پیشرو و انتخاب رایج است.

جایگاه این فصل در چرخهٔ توسعه

مسیر معمول و منطقی توسعه چنین است:

1. توسعه و تست در شبکهٔ خصوصی محلی یا محیط شبیه‌سازی‌شده؛
2. استقرار روی testnet عمومی؛
3. پس از موفقیت تست‌ها، استقرار روی mainnet عمومی.

بسیاری از توسعه‌دهندگان این مسیر را کوتاه می‌کنند: فقط در شبیه‌ساز محلی کار می‌کنند و مستقیم به mainnet یا شبکهٔ خصوصی تولید می‌روند. راه‌اندازی شبکهٔ خصوصی زمان‌برتر از برپا کردن شبیه‌ساز بلاک‌چین است، پس حذف آن زمان رسیدن به تولید را کم می‌کند. ابزارهای جدید مانند Truffle، Ganache و MetaMask کار را ساده‌تر کرده‌اند و در فصل ۱۳ و ۱۴ (Web3) معرفی می‌شوند.

چرا اول ابزار بومی؟

نویسنده عمداً ابتدا از ابزارهای خط فرمان و استقرار دستی استفاده می‌کند. استدلال این است که فریم‌ورک‌ها کار را آسان می‌کنند اما جزئیات پشت صحنه را پنهان می‌کنند، و برای مبتدی فهم این جزئیات پایه‌ای ضروری است. پس نخست با ابزار بومی کار می‌کنیم و بعد سراغ فریم‌ورک‌هایی مثل Truffle می‌رویم.

شبکه‌های آزمایشی (Test networks)

اتصال Geth به شبکهٔ آزمایشی با پرچم geth --testnet انجام می‌شود. خروجی نوع شبکه و روند دانلود بلاک‌چین را نشان می‌دهد. برای ردیابی تراکنش‌ها و بلاک‌های Ropsten می‌توان از block explorer آن در ropsten.etherscan.io استفاده کرد.

شبکه‌های آزمایشی مختلفی وجود دارند (Frontier، Morden، Ropsten، Rinkeby) و Geth با پرچم‌های خط فرمان به آن‌ها وصل می‌شود:

راه‌اندازی شبکهٔ خصوصی (Setting up a private net)

شبکهٔ خصوصی یک بلاک‌چین کاملاً جدید می‌سازد که بلاک پیدایش (genesis) و شناسهٔ شبکهٔ خودش را دارد. سه مؤلفهٔ لازم است:

1. شناسهٔ شبکه (Network ID)؛
2. فایل genesis؛
3. پوشهٔ داده (data directory) برای ذخیرهٔ داده‌های بلاک‌چین؛ ذکر آن اجباری نیست، اما اگر چند بلاک‌چین روی سیستم فعال باشد باید پوشهٔ جدا مشخص شود.

در mainnet، Geth گره‌های راه‌انداز (boot nodes) را که در خود کلاینت ثابت‌اند به‌طور خودکار پیدا می‌کند. اما در شبکهٔ خصوصی باید با پرچم‌ها و پیکربندی مناسب تنظیم شود تا بتواند همتاها را پیدا کند یا توسط آن‌ها پیدا شود.

توصیهٔ امنیتی: کشف گره را غیرفعال کنید تا گره‌های اینترنت شبکهٔ خصوصی شما را پیدا نکنند. اگر شبکهٔ دیگری عیناً همین genesis و network ID را داشته باشد ممکن است به شبکهٔ شما وصل شود. احتمالش بسیار کم است، ولی غیرفعال‌سازی کشف یک رویهٔ خوب است.

شناسهٔ شبکه

هر عدد مثبتی جز ۱ (mainnet) و ۳ (Ropsten) مجاز است. در مثال کتاب عدد ۷۸۶ انتخاب شده است.

فایل genesis

فایل genesis فیلدهای لازم برای بلاک اول سفارشی را تعریف می‌کند. این بلاک به هیچ بلاک قبلی اشاره نمی‌کند. پروتکل اتریوم بررسی می‌کند که هیچ گره دیگری بدون داشتن همین بلاک پیدایش نتواند در اجماع مشارکت کند؛ شناسهٔ زنجیره (chain ID) هم معمولاً برای شناسایی شبکه به کار می‌رود. فایل با پسوند JSON ذخیره می‌شود (مثلاً privategenesis.json). اتر اولیه را می‌توان با بخش alloc به آدرس‌ها اختصاص داد (مقدار به Wei)، اما معمولاً لازم نیست چون در شبکهٔ خصوصی ماین کردن اتر بسیار سریع است.

پارامترهای فایل genesis نمونه:

پوشهٔ داده

جایی است که داده‌های شبکهٔ خصوصی ذخیره می‌شود؛ در مثال ~/etherprivate/.

پرچم‌های Geth و معنی آن‌ها

• --nodiscover: گره را قابل کشف خودکار نمی‌کند، حتی اگر genesis و network ID یکسان باشد.
• --maxpeers: حداکثر همتاهای متصل؛ مقدار ۰ یعنی هیچ‌کس نمی‌تواند وصل شود (مناسب تست خصوصی).
• --rpc: فعال‌سازی رابط RPC.
• --rpcapi: فهرست APIهای مجاز روی RPC (مثل eth و web3).
• --rpcport: درگاه TCP برای RPC (مثلاً ۹۹۹۹).
• --rpccorsdomain: آدرسی که اجازهٔ اتصال و اجرای عملیات RPC دارد؛ CORS مخفف cross-origin resource sharing است.
• --port: درگاه TCP برای شنیدن اتصال‌های ورودی همتاها.
• --identity: رشته‌ای برای نام‌گذاری گره خصوصی.

گره‌های ایستا (Static nodes)

اگر لازم باشد گره فقط به مجموعهٔ مشخصی از همتاها وصل شود، می‌توان آن‌ها را در فایل static-nodes.json داخل همان پوشه‌ای که chaindata و keystore هستند نوشت. هر مدخل یک نشانی enode است: شناسهٔ گره (رشتهٔ هگز بلند) به‌علاوهٔ IP عمومی و درگاه TCP. این روش در شبکهٔ خصوصی برای کشف گره‌ها مفید است.

راه‌اندازی شبکه

مراحل کار:

1. مقداردهی اولیه: دستور geth init <genesis.json> --datadir <dir> بلاک پیدایش را می‌سازد و خروجی موفقیت آن را نشان می‌دهد.
2. اجرای گره: با --datadir، --networkid 786، --rpc، --rpcapi 'web3,eth,net,debug,personal' و --rpccorsdomain '*'.
3. اتصال کنسول: با geth attach ipc:<path>/geth.ipc به‌وسیلهٔ IPC (ارتباط بین‌فرایندی روی همان ماشین) به گرهٔ در حال اجرا وصل می‌شویم و کنسول تعاملی JavaScript باز می‌شود.

هنگام شروع هشداری دیده می‌شود: «No etherbase set and no accounts found». چون در شبکهٔ جدید هنوز حسابی نیست و هیچ حسابی به‌عنوان دریافت‌کنندهٔ پاداش ماینینگ (etherbase) تعیین نشده است. راه‌حل: ساخت حساب و تنظیم آن به‌عنوان etherbase.

کار در کنسول Geth

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

• personal.newAccount("...") حساب جدید می‌سازد و آدرس برمی‌گرداند (رمز نمونه فقط مثال است).
• miner.setEtherbase(personal.listAccounts[0]) آن حساب را دریافت‌کنندهٔ پاداش می‌کند.
• eth.getBalance(eth.coinbase) موجودی را نشان می‌دهد (در ابتدا صفر).
• miner.start(2) ماینینگ را با دو thread آغاز می‌کند. در نخستین اجرا ابتدا DAG (ساختار دادهٔ لازم برای الگوریتم اثبات کار اتریوم) تولید می‌شود، سپس پیام‌های «Mined … blocks» ظاهر می‌شود.
• miner.stop() ماینینگ را متوقف می‌کند.

پس از ماین کردن، موجودی به مقدار قابل‌توجهی می‌رسد (در مثال حدود ۸۵ اتر برحسب Wei). دلیل سرعت این است که در شبکهٔ خصوصی رقیبی در حل اثبات کار نیست و دشواری هم در genesis پایین تنظیم شده است.

نکات کار با کنسول: دو بار فشردن Tab فهرست اشیا/متدهای موجود را نشان می‌دهد و تکمیل خودکار دستور را انجام می‌دهد؛ تایپ نام یک شیء (مثلاً net;) همهٔ متدهای آن را فهرست می‌کند.

دستورهای کاربردی دیگر:

برای from و to می‌توان از personal.listAccounts[0] و [1] هم استفاده کرد.

اجرای Mist روی شبکهٔ خصوصی

Mist (کیف پول و مرورگر رسمی اتریوم در آن زمان) را می‌توان به شبکهٔ خصوصی وصل کرد. فایل اجرایی در لینوکس معمولاً در /opt/Ethereum و در macOS داخل بستهٔ برنامهٔ Ethereum Wallet است. دو روش اتصال به Geth هست:

• IPC: با اشاره به فایل geth.ipc؛
• RPC/HTTP: با آدرس http://127.0.0.1:8545. Mist هشدار می‌دهد که این روش امنیت کمتری دارد؛ چون شبکه محلی است و به اینترنت وصل نیست و عمومی هم نمی‌شود، می‌توان تأیید کرد.

اتصال از راه RPC برای حالتی مفید است که Geth و Mist روی دو ماشین مختلف باشند. پس از اتصال، رابط کاربری حالت PRIVATE-NET را نشان می‌دهد و تمام امکانات کیف پول، مدیریت حساب و استقرار قرارداد در دسترس است. بخش‌های رابط:

• WALLETS: باز کردن کیف پول‌ها؛
• SEND: ارسال وجه به حساب‌های دیگر؛
• CONTRACTS: ساخت و استقرار قرارداد؛
• BALANCE: نمایش موجودی اتر.

استقرار قرارداد با Mist

Mist محیطی دارد که در آن می‌توان قرارداد Solidity نوشت و مستقر کرد. چون Solidity هنوز معرفی نشده، هدف این بخش تجربهٔ فرایند استقرار و تعامل است (کد در فصل‌های ۱۳ و ۱۴ توضیح داده می‌شود). قرارداد نمونه SimpleContract2 است:

• یک متغیر حالت z از نوع uint دارد؛
• سه تابع addition (جمع ورودی با ۵)، difference (تفریق ۵) و division (تقسیم بر ۵) که نتیجه را در z می‌نویسند و برمی‌گردانند؛
• تابع فقط‌خواندنی currValue که مقدار فعلی z را برمی‌گرداند.

مراحل استقرار در Mist:

1. چسباندن کد در بخش CONTRACTS؛
2. پس از بررسی نبود خطای نحوی، انتخاب قرارداد از منوی «SELECT CONTRACT TO DEPLOY» و زدن Deploy؛
3. وارد کردن رمز حساب و زدن SEND TRANSACTION؛
4. پس از ماین شدن، تراکنش در فهرست تراکنش‌های Mist ظاهر می‌شود.

تعامل با قرارداد: منوی توابع قرارداد گزینه‌های READ FROM CONTRACT (خواندن بدون تغییر حالت) و WRITE TO CONTRACT (تغییر حالت با تراکنش) را دارد. تابع مطلوب انتخاب می‌شود، مقدار ورودی وارد می‌شود، حساب اجراکننده (Execute from) تعیین می‌شود و با EXECUTE (و تأیید رمز و SEND TRANSACTION) تابع فراخوانی می‌شود.

Block explorer برای شبکهٔ خصوصی

برای دیدن بلاک‌ها و تراکنش‌های شبکهٔ محلی می‌توان از explorer متن‌باز etherparty/explorer در GitHub استفاده کرد. مراحل:

1. git clone مخزن؛
2. ورود به پوشه و اجرای npm start (به Node.js نیاز دارد؛ نصب ممکن است حدود ۵ دقیقه طول بکشد) که سرور HTTP راه می‌اندازد؛
3. اجرای Geth با --rpc و --rpccorsdomain برابر http://localhost:8000 یا '*'؛
4. باز کردن localhost:8000 در مرورگر.

جایگزین: راه‌اندازی یک وب‌سرور سریع با پایتون (python -m SimpleHTTPServer 7777). اگر Geth با پارامترهای درست (به‌ویژه --rpccorsdomain) اجرا نشود، explorer خطای اتصال/CORS می‌دهد. راه‌حل، راه‌اندازی مجدد Geth با --rpcapi 'web3,eth,net,debug,personal' و --rpccorsdomain '*' است. ستاره یعنی هر IP می‌تواند وصل شود؛ به‌جای آن می‌توان IP محلی را گذاشت.

جمع‌بندی

• Geth با --testnet و --rinkeby به شبکه‌های آزمایشی وصل می‌شود؛ Ropsten از نوع PoW و Rinkeby از نوع PoA است.
• شبکهٔ خصوصی سه عنصر لازم دارد: network ID (غیر از ۱ و ۳)، فایل genesis و پوشهٔ داده؛ و توصیه می‌شود کشف گره با --nodiscover خاموش شود.
• با geth init بلاک پیدایش ساخته می‌شود، و با geth attach کنسول JavaScript برای ساخت حساب، تعیین etherbase، ماینینگ، پرس‌وجو (gasPrice، blockNumber، RLP) و ارسال تراکنش در دسترس است.
• Mist امکان مدیریت حساب، استقرار قرارداد Solidity و تعامل خواندن/نوشتن با آن را روی شبکهٔ خصوصی فراهم می‌کند؛ و explorer محلی برای مشاهدهٔ بلاک‌ها و تراکنش‌ها به کار می‌رود.
• فصل بعد ابزارها، زبان‌ها و فریم‌ورک‌های توسعهٔ قرارداد هوشمند را معرفی می‌کند.

فصل ۱۳ — ابزارها و فریم‌ورک‌های توسعه (Development Tools and Frameworks)

مقدمه

این فصل ابزارها، زبان‌ها و فریم‌ورک‌هایی را معرفی می‌کند که برای توسعهٔ قرارداد هوشمند روی اتریوم استفاده می‌شوند و در بخش پایانی، ساختارهای زبان Solidity را (که در آن زمان رایج‌ترین زبان قرارداد نویسی است) با جزئیات بررسی می‌کند. سرفصل‌ها:

• ابزارها، IDEها و کلاینت‌ها: Remix، Ganache، EthereumJS، TestRPC، MetaMask، Truffle؛
• پیش‌نیازها: Node و مدیر بستهٔ NPM؛
• ابزارها و کتابخانه‌های دیگر.

کتاب یک نمودار طبقه‌بندی (taxonomy) از اکوسیستم توسعهٔ اتریوم ارائه می‌کند. این نمودار همهٔ ابزارها را شامل نمی‌شود و فقط رایج‌ترین‌ها و آن‌هایی را که در مثال‌های فصل استفاده می‌شوند نشان می‌دهد. تمرکز اصلی روی Geth، Remix IDE، Solidity، Ganache، MetaMask، solc و Truffle است و پیش‌نیازهایی مثل Node کوتاه مرور می‌شود. فهرست جامع‌تر ابزارها در مستندات ethdocs.org در دسترس است.

زبان‌ها (Languages)

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

کامپایلرها

کامپایلر کد سطح‌بالای قرارداد را به قالبی تبدیل می‌کند که محیط اجرای اتریوم می‌فهمد. رایج‌ترین آن‌ها کامپایلر Solidity است.

کامپایلر Solidity (solc)

solc کد Solidity را به بایت‌کد EVM تبدیل می‌کند تا ماشین مجازی اتریوم روی بلاک‌چین اجرا کند.

• نصب روی اوبونتو: apt-get install solc (در صورت نبود PPA ابتدا add-apt-repository ppa:ethereum/ethereum و apt-get update).
• نصب روی macOS: با Homebrew (brew tap ethereum/ethereum و brew install solidity).
• بررسی نسخه: solc --version (در مثال نسخهٔ ۰٫۴٫۱۹).

دستورهای نمونه روی قراردادی ساده به نام Addition.sol:

دو فایل خروجی: Addition.abi (رابط باینری برنامه به قالب JSON) و Addition.bin (نمایش هگز باینری قرارداد).

ABI (Application Binary Interface) اطلاعات توابع و رویدادهای قرارداد را رمزگذاری می‌کند و واسطی میان بایت‌کد سطح EVM و کد سطح‌بالای برنامه است. برنامهٔ بیرونی برای تعامل با قرارداد مستقرشده هم به ABI و هم به آدرس قرارداد نیاز دارد. گزینهٔ --help بقیهٔ امکانات solc را نشان می‌دهد، اما همین دستورها برای بیشتر نیازهای کامپایل، ABI و تخمین gas کافی است.

محیط‌های توسعهٔ یکپارچه (IDE) و Remix

بیشتر IDEهای Solidity آنلاین و وب‌محورند. Remix (که قبلاً browser Solidity نام داشت) رایج‌ترین IDE برای ساخت و اشکال‌زدایی قراردادهاست (remix.ethereum.org). Remix روی بلاک‌چین زنده اجرا نمی‌شود و محیط شبیه‌سازی‌شده‌ای است برای استقرار، تست و دیباگ.

• سمت چپ: ویرایشگر کد با رنگ‌آمیزی نحو و قالب‌بندی؛ سمت راست: ابزارهای استقرار، اشکال‌زدایی، تست و تعامل با قرارداد.
• قابلیت‌ها: تعامل با تراکنش‌ها، اتصال به JavaScript VM، پیکربندی محیط اجرا، دیباگر، تأیید صوری (formal verification) و تحلیل ایستا (static analysis).
• محیط‌های اجرا: JavaScript VM (شبیه‌ساز داخل مرورگر)، Injected Web3 (وقتی Mist یا MetaMask محیط را فراهم کرده‌اند)، و Web3 Provider (اتصال به کلاینت محلی مثل geth از راه IPC یا RPC روی HTTP).
• دیباگر EVM: ردیابی و تحلیل دقیق بایت‌کد. کد منبع به دستورهای EVM تبدیل می‌شود و کاربر می‌تواند دستورها را یکی‌یکی اجرا کند و ببیند کد در زمان اجرا چه می‌کند. در پنجره، کد در بالا و لاگ خروجی (پیام‌های کامپایل و اجرا) پایین‌تر است.

ابزارها و کتابخانه‌ها

پیش‌نیاز: Node

بیشتر ابزارها بر پایهٔ Node.js و مدیر بستهٔ npm هستند. نصب Node نسخهٔ ۷ در اوبونتو با اسکریپت nodesource (setup_7.x) و سپس apt-get install nodejs انجام می‌شود.

EthereumJS و TestRPC

گاهی نمی‌شود روی testnet تست کرد، mainnet هم جای تست نیست و راه‌اندازی شبکهٔ خصوصی هم وقت‌گیر است. TestRPC (از EthereumJS) رفتار کلاینت geth را شبیه‌سازی می‌کند و تست سریع را ممکن می‌سازد. نصب: npm install -g ethereumjs-testrpc؛ اجرا با دستور testrpc (در یک ترمینال می‌ماند و در ترمینال دیگر روی قراردادها کار می‌کنیم). TestRPC به‌طور خودکار ۱۰ حساب با کلید خصوصی و یک کیف پول HD می‌سازد و روی درگاه TCP ۸۵۴۵ گوش می‌دهد.

Ganache

Ganache جدیدترین ابزار این دسته و جایگزین TestRPC است، با رابط گرافیکی برای مشاهدهٔ تراکنش‌ها، بلاک‌ها و آدرس‌ها. یک بلاک‌چین شخصی کامل با پشتیبانی از Byzantium است که محیط تست محلی فراهم می‌کند. بر پایهٔ پیاده‌سازی JavaScript اتریوم ساخته شده و block explorer و ماینینگ داخلی دارد؛ بنابراین تست محلی بسیار ساده می‌شود. دانلود از سایت Truffle Framework.

MetaMask

MetaMask افزونهٔ مرورگرهای Firefox و Chrome است که تعامل با بلاک‌چین اتریوم را ممکن می‌کند. شیء web3 را داخل بافت JavaScript صفحه‌های وب تزریق می‌کند و DApp ها می‌توانند مستقیم با بلاک‌چین تعامل کنند. ویژگی‌ها:

• مدیریت حساب و نقش تأییدکننده: پیش از ارسال هر تراکنش به بلاک‌چین، رابط امنی تراکنش را نشان می‌دهد تا کاربر تأیید یا رد کند.
• اتصال به شبکه‌های مختلف اتریوم (انتخاب از منوی شبکه).
• اتصال به هر RPC سفارشی: شبکهٔ خصوصی محلی یا راه دور، یا بلاک‌چین‌های محلی مثل Ganache و TestRPC.
• ثبت تراکنش‌های هر حساب و نمایش آن‌ها.

Truffle

Truffle محیط توسعه‌ای است که تست و استقرار قراردادها را ساده‌تر می‌کند. قابلیت‌ها:

• کامپایل و لینک قراردادها؛
• چارچوب تست خودکار با Mocha و Chai؛
• استقرار روی هر شبکهٔ خصوصی، عمومی یا testnet؛
• خط لولهٔ دارایی‌ها (asset pipeline) برای پردازش فایل‌های JavaScript و آماده کردن آن‌ها برای مرورگر.

نصب: ابتدا باید Node موجود باشد (بررسی نسخه، مثلاً v7.2.1) و بعد sudo npm install -g truffle (در مثال نسخهٔ [email protected]). اجرای truffle راهنمای استفاده را نشان می‌دهد. روش دیگر کلون کردن مخزن ConsenSys/truffle با git است. استفادهٔ عملی از Truffle در فصل ۱۴ (Web3) می‌آید.

توسعه و استقرار قرارداد

فرایند به چهار گام کلی تقسیم می‌شود: نوشتن، تست، تأیید (verification) و استقرار. گام اختیاریِ بعد از استقرار، ساخت رابط کاربری و ارائه با وب‌سرور است. قراردادهایی که ورودی یا نظارت انسانی لازم ندارند ممکن است به رابط وب نیاز نداشته باشند، ولی معمولاً رابط وب لازم است.

نوشتن

کد Solidity را در هر ویرایشگر متنی می‌توان نوشت. برای Vim، Atom و ویرایشگرهای دیگر افزونه‌هایی برای رنگ‌آمیزی و قالب‌بندی وجود دارد. Visual Studio Code محبوب شده و افزونهٔ Solidity آن (قابل نصب از بخش Extensions) رنگ‌آمیزی، قالب‌بندی و IntelliSense می‌دهد.

تست

تست معمولاً خودکار است؛ Truffle از Mocha استفاده می‌کند. تست دستی عملکردی هم با Remix ممکن است (اجرای دستی توابع و بررسی نتیجه). مسیر معمول: ابتدا در محیط شبیه‌سازی‌شده (TestRPC، Ganache) یا شبکهٔ خصوصی، بعد testnet عمومی و در نهایت بلاک‌چین زنده (Byzantium). تمام این مراحل، همراه با تأیید و ساخت رابط وب، در فصل ۱۴ پوشش داده می‌شود.

زبان Solidity

Solidity زبان تخصصی حوزه (domain-specific) برای نوشتن قرارداد در اتریوم است و نحوی نزدیک به JavaScript و C دارد. در زمان نگارش پرطرفدارترین زبان بود، اما هنوز به پختگی و استانداردسازی زبان‌های جاافتادهٔ Java، C یا C# نرسیده است.

ویژگی‌های کلی:

• ایستا تایپ (statically typed): نوع هر متغیر (حالت یا محلی) در زمان کامپایل مشخص می‌شود. فایده: خطاهایی مثل تفسیر اشتباه نوع داده زودتر و پیش از اجرا گرفته می‌شود، که در بلاک‌چین هزینهٔ زیادی دارد.
• پشتیبانی از وراثت، کتابخانه‌ها و انواع مرکب تعریف‌شده توسط کاربر.
• زبان قرارداد-محور است: قرارداد (contract) معادل کلاس در زبان‌های شیء‌گرا است.

انواع داده (Types)

دو دستهٔ کلی: انواع مقداری (value) و انواع مرجعی (reference).

انواع مقداری

• Boolean (bool): مقادیر true و false.
• اعداد صحیح: int (علامت‌دار) از int8 تا int256 با گام ۸ بیت، و uint (بی‌علامت) از uint8 تا uint256. uint مترادف uint256 است. انتخاب اندازه بسته به تعداد بیت لازم است. با کلیدواژهٔ constant برای آن‌ها فضای ذخیره‌سازی رزرو نمی‌شود و هر استفاده با مقدار واقعی جایگزین می‌شود (مثلاً uint constant z = 10+10;). متغیرهای حالت بیرون از بدنهٔ تابع تعریف می‌شوند و تا زمانی که قرارداد باقی است، بسته به سطح دسترسی در دسترس‌اند.
• Address: مقدار ۱۶۰ بیتی (۲۰ بایت) با اعضای کاربردی:
  • balance: موجودی آدرس به Wei؛
  • send: ارسال اتر به آدرس؛ نتیجه true یا false است (مثال: اگر موجودی گیرنده کمتر از ۱۰ و فرستنده بیشتر از ۵۰ بود، ۲۰ بفرست)؛
  • call، callcode و delegatecall: برای تعامل با توابعی که ABI ندارند؛ با احتیاط چون ایمنی نوع و امنیت قرارداد را تحت تأثیر قرار می‌دهند.
• آرایه‌های بایتی: اندازه‌ثابت (bytes1 تا bytes32) و اندازه‌متغیر (bytes برای بایت خام و string برای رشتهٔ UTF-8). چون مقدار برگشت داده می‌شوند، فراخوانی‌شان gas خرج دارد؛ عضو length طول را می‌دهد. مثال: bytes32[10] bankAccounts; (ثابت) و bytes32[] trades; با trades.length.
• لیترال‌ها (Literals): عددی (مثلاً uint8 x = 2;)، رشته‌ای (با نقل‌قول تکی یا دوتایی)، و هگزادسیمال با پیشوند hex (مثلاً hex'AABBCC').
• Enum: نوع تعریف‌شده توسط کاربر، مثلاً enum Order {Filled, Placed, Expired}؛ تبدیل صریح از/به انواع صحیح مجاز است.
• انواع تابع: دو دسته‌اند. internal فقط در بافت قرارداد جاری قابل استفاده‌اند؛ external از راه فراخوانی‌های بیرونی صدا زده می‌شوند. تابع constant چیزی را در قرارداد تغییر نمی‌دهد و فقط مقدار برمی‌گرداند، و هزینهٔ gas ندارد (این پیاده‌سازی مفهوم «call» فصل قبل است). قالب کلی تعریف: نام تابع، نوع و نام پارامترها، internal/external، و اختیاری constant، payable و returns.

انواع مرجعی

این انواع (که «انواع مرکب» هم گفته می‌شوند) به‌صورت مرجع منتقل می‌شوند.

• Array: مجموعهٔ پیوستهٔ عناصر هم‌نوع و هم‌اندازه در حافظه؛ اعضا: length و push. مثال: uint[] OrderIds;
• Struct: گروه‌بندی منطقی داده‌های ناهمگون و تعریف نوع جدید. مثال کتاب ساختار Trade با فیلدهای tradeid، quantity، price و trader است که با نام فیلدها مقداردهی می‌شود.
• محل داده (Data location): مشخص می‌کند نوع مرکب (آرایه و struct) کجا ذخیره شود: storage یا memory. چون کپی بین حافظه و storage گران است، تعیین محل به کنترل مصرف gas کمک می‌کند. محل سوم calldata است برای آرگومان‌های تابع. قواعد پیش‌فرض: پارامترهای توابع external در calldata، پارامترهای معمول توابع در memory، سایر متغیرهای محلی در storage، و متغیرهای حالت الزاماً در storage.
• Mapping: نگاشت کلید به مقدار؛ همهٔ مقادیر از ابتدا صفر مقداردهی شده‌اند. مثال: mapping (address => uint) offers; یا mapping (string => uint) bids; و bids["packt"] = 10;. معادل دیکشنری یا جدول هش است.

متغیرهای سراسری (Global variables)

متغیرها و توابعی همیشه در فضای نام سراسری هستند و دربارهٔ بلاک‌ها، تراکنش‌ها، توابع رمزنگاری و آدرس‌ها اطلاعات می‌دهند. نمونه‌ها:

• keccak256(...) هش Keccak-256 آرگومان را برمی‌گرداند؛
• ecrecover(hash, v, r, s) آدرس متناظر با کلید عمومی را از امضای منحنی بیضوی (elliptic curve) بازیابی می‌کند؛
• block.number شمارهٔ بلاک جاری.

ساختارهای کنترلی

if...else، do، while، for، break، continue و return مثل C یا JavaScript کار می‌کنند. کتاب مثال‌های کوتاهی می‌آورد: شرط روی x و مقداردهی y یا z، حلقهٔ do/while که x را تا وقتی z بزرگ‌تر از ۱ است افزایش می‌دهد، حلقهٔ for با break وقتی z به ۵ برسد، و return برای پایان دادن به تابع و برگرداندن مقدار اختیاری.

رویدادها (Events)

رویدادها اطلاعاتی را در لاگ‌های EVM ثبت می‌کنند و برای اطلاع‌رسانی تغییر یا وقوع شرطی در قرارداد به رابط‌های بیرونی مفیدند. لاگ‌ها در لاگ تراکنش‌های بلاک‌چین ذخیره می‌شوند و از داخل قراردادها قابل خواندن نیستند؛ فقط سازوکاری برای اعلان تغییر وضعیت هستند. در مثال valueChecker، تابع Matcher اگر ورودی x از price (برابر ۱۰) کمتر نباشد، رویداد valueEvent(true) را منتشر می‌کند و true برمی‌گرداند.

وراثت (Inheritance)

با کلیدواژهٔ is یک قرارداد از قرارداد دیگر مشتق می‌شود و به همهٔ اعضای غیرخصوصی (non-private) والد دسترسی دارد. در مثال، valueChecker2 is valueChecker تابع Matcher2 را اضافه می‌کند که price+10 را برمی‌گرداند. اگر price را private کنیم، قرارداد مشتق دیگر نمی‌تواند آن را ببیند و Remix خطای DeclarationError: Undeclared identifier می‌دهد.

کتابخانه‌ها (Libraries)

کتابخانه فقط یک بار در آدرس مشخصی مستقر می‌شود و کدش با opcodeهای CALLCODE یا DELEGATECALL در EVM فراخوانی می‌شود. هدف استفادهٔ مجدد از کد است؛ مثل قراردادی است که نقش قرارداد پایه برای قرارداد فراخواننده را دارد. مثال: کتابخانهٔ Addition با تابع Add که با import وارد می‌شود و به شکل Addition.Add(100,100) صدا زده می‌شود. محدودیت‌ها: متغیر حالت ندارند، وراثت ندارند (نه ارث‌بر نه ارث‌بخش) و نمی‌توانند اتر دریافت کنند (برخلاف قرارداد).

توابع (Functions)

تابع ماژول کدی وابسته به قرارداد است و شامل نام، پارامترهای اختیاری، مشخصه‌دسترسی، کلیدواژهٔ اختیاری constant و نوع بازگشتی اختیاری می‌شود. مثال کتاب: orderMatcher(uint x) private constant returns(bool).

• امضای تابع (Function signature): چهار بایت اول هش Keccak-256 رشتهٔ امضا؛ در Remix دیده می‌شود (مثلاً Matcher امضای d99c89cb دارد) و برای ساخت رابط‌ها به کار می‌رود.
• پارامترهای ورودی و خروجی: با قالب «نوع و نام». یک تابع می‌تواند چند مقدار برگرداند (تا ۱۴ مقدار از نوع‌های مختلف)؛ نام پارامترهای بازگشتی استفاده‌نشده را می‌توان حذف کرد.
• فراخوانی داخلی: فراخوانی تابع‌های همان قرارداد؛ در سطح بایت‌کد EVM به JUMP ساده تبدیل می‌شود.
• فراخوانی خارجی: با message call از یک قرارداد به قرارداد دیگر؛ همهٔ پارامترها به حافظه کپی می‌شوند. فراخوانی تابع داخلی با this هم خارجی محسوب می‌شود (this اشاره‌گر به قرارداد جاری است و به آدرس قابل تبدیل است).
• تابع fallback: تابع بی‌نام و بدون آرگومان و مقدار بازگشتی که هر بار اتر دریافت می‌شود اجرا می‌شود و وقتی هیچ امضای دیگری مطابقت نکند هم اجرا می‌شود. اگر قرارداد قرار است اتر بگیرد، باید پیاده‌سازی شود و با payable علامت بخورد؛ وگرنه استثنا رخ می‌دهد و اتر برمی‌گردد. در مثال کتاب بدنهٔ آن throw است که وضعیت را به قبل از فراخوانی برمی‌گرداند؛ جایگزین می‌تواند ثبت یک event برای هشدار باشد.
• تابع modifier: رفتار توابع دیگر را تغییر می‌دهد و معمولاً شرطی را پیش از اجرا بررسی می‌کند (شبیه guard). علامت _ در modifier با بدنهٔ واقعی تابع محافظت‌شده جایگزین می‌شود.
• تابع سازنده (Constructor): اختیاری، هم‌نام قرارداد، فقط یک بار هنگام ساخت قرارداد اجرا می‌شود و بعداً قابل فراخوانی نیست؛ فقط یکی مجاز است، پس overloading نداریم.
• مشخصه‌های دسترسی:

• اصلاح‌گرهای رفتاری تابع: pure (ممنوعیت دسترسی یا تغییر state)، view (ممنوعیت تغییر state)، payable (اجازهٔ دریافت اتر همراه فراخوانی) و constant (در آن زمان مشابه view/pure).
• throw: اجرا را متوقف و همهٔ تغییرات حالت را برمی‌گرداند؛ ولی gas باقی‌مانده به فرستنده بازنمی‌گردد چون همه مصرف می‌شود.

ساختار فایل مبدأ Solidity

• pragma نسخه: برای رعایت سازگاری با نسخه‌های بعدی solc، مثلاً pragma solidity ^0.5.0 یعنی نسخه‌های کمتر از ۰٫۵٫۰ و نسخه‌های ۰٫۶٫۰ به بعد کامپایل نمی‌کنند.
• import: وارد کردن نمادها از فایل‌های Solidity دیگر به محدودهٔ سراسری فعلی، شبیه JavaScript.
• کامنت‌ها: مانند C؛ چندخطی با /* … */ و تک‌خطی با //.

کتاب یک برنامهٔ نمونه در Remix نشان می‌دهد که pragma، import و کامنت را کنار هم دارد. مستندات کامل و رهنمودهای کدنویسی در solidity.readthedocs.io است و زبان همچنان در حال تکامل است.

جمع‌بندی

• برای توسعهٔ اتریوم مجموعه‌ای از ابزارها هست: solc برای کامپایل و تولید ABI/bytecode/تخمین gas، Remix برای نوشتن، دیباگ و تست در مرورگر، TestRPC و Ganache برای بلاک‌چین شخصی و سریع محلی، MetaMask برای اتصال DApp به بلاک‌چین و مدیریت حساب، و Truffle برای کامپایل، تست خودکار (Mocha/Chai) و استقرار.
• زبان‌های Mutan، LLL و Serpent منسوخ شده‌اند؛ Solidity زبان غالب است و Vyper گزینهٔ آزمایشی تازه‌ای است.
• فرایند توسعه شامل نوشتن، تست، تأیید و استقرار است؛ مسیر توصیه‌شده از شبیه‌ساز/شبکهٔ خصوصی به testnet و سپس mainnet می‌رود.
• Solidity زبان ایستا تایپ و قرارداد-محور با انواع مقداری و مرجعی، رویداد، وراثت، کتابخانه، modifier، تابع fallback و constructor، و مشخصه‌های دسترسی است؛ نکات مهم آن شامل هزینهٔ gas در انتقال داده، محل ذخیرهٔ داده و احتیاط در call/delegatecall است.
• Node و npm پیش‌نیاز بیشتر ابزارهای JavaScript محور هستند؛ فصل بعد Web3، یعنی API جاوااسکریپت برای ارتباط با اتریوم، را معرفی می‌کند.

فصل ۱۴ — معرفی Web3 (Introducing Web3)

مقدمه

این فصل جنبهٔ کاملاً عملی و پروژه‌محور دارد. هدف آن است که خواننده ببیند یک قرارداد هوشمند (smart contract) در عمل چگونه نوشته، آزمایش و روی بلاک‌چین اتریوم مستقر (deploy) می‌شود و چگونه یک رابط کاربری وب (HTML و JavaScript) با آن تعامل می‌کند. ابزارهایی که در طول فصل به کار می‌روند عبارت‌اند از:

• کتابخانهٔ Web3 (web3.js) برای ارتباط با گره اتریوم؛
• کلاینت geth و کنسول آن (console / attach)؛
• Remix IDE برای نوشتن، شبیه‌سازی و دریافت اسکریپت استقرار؛
• Ganache به‌عنوان بلاک‌چین محلی آزمایشی؛
• فریم‌ورک Truffle برای کامپایل، مهاجرت (migration) و تست؛
• سرویس اوراکل Oraclize؛
• شبکهٔ ذخیره‌سازی غیرمتمرکز IPFS و پروتکل‌های Swarm و Whisper؛
• و در پایان، نگاهی کوتاه به دفترهای کل توزیع‌شدهٔ مجوزدار.

فصل از ابزار ساده شروع می‌کند و به‌تدریج به یک پروژهٔ کامل (ثبت اثبات وجود ایده) می‌رسد.

Web3

Web3 یک کتابخانهٔ JavaScript است که از راه RPC (فراخوانی رویه از راه دور) با یک گره اتریوم صحبت می‌کند. این کتابخانه فقط متدهایی را در اختیار می‌گذارد که روی گره از طریق RPC فعال شده باشند. به همین دلیل می‌توان رابط‌های کاربری ساخت که از طریق Web3 با قراردادهای مستقرشده روی بلاک‌چین کار کنند.

فعال‌سازی RPC در geth

برای در دسترس قرار دادن متدها، geth با چند سوئیچ اجرا می‌شود:

با دستور geth attach ipc:<مسیر>/geth.ipc می‌توان به گرهٔ در حال اجرا وصل شد و در کنسول JavaScript آن شیء web3 را پرس‌وجو کرد.

استقرار قرارداد با geth و Web3

نمونهٔ قرارداد این بخش valueChecker است (با pragma solidity ^0.4.0): متغیر price برابر ۱۰، رویداد valueEvent و تابع Matcher(uint8 x) که اگر x بزرگ‌تر یا مساوی قیمت باشد رویداد را صادر می‌کند و true برمی‌گرداند (در غیر این صورت چیزی برنمی‌گرداند، یعنی مقدار پیش‌فرض false). مراحل کار:

1. اجرای geth با RPC فعال و وصل‌شدن به آن با یک ترمینال دوم (geth attach).
2. چسباندن کد در Remix IDE (که در فصل ۱۳ معرفی شد) فقط برای گرفتن «شیء استقرار Web3».
3. در بخش Details در Remix، روی آیکون کنار عنوان WEB3DEPLOY کلیک می‌شود تا اسکریپت استقرار کپی شود. این اسکریپت شامل سه چیز است: ABI قرارداد (به‌شکل JSON) که به web3.eth.contract([...]) داده می‌شود، فیلد data که بایت‌کد کامپایل‌شدهٔ قرارداد (رشتهٔ هگز بلند با پیشوند 0x6060604052…) است، و gas برابر ۴٬۷۰۰٬۰۰۰ همراه با callback که پس از استخراج تراکنش، آدرس قرارداد و transactionHash را چاپ می‌کند.
4. اطمینان از باز بودن حساب: با personal.listAccounts[0] حساب اول (در مثال با آدرسی که با 0xcf61d2… شروع می‌شود) فهرست و با personal.unlockAccount(...) و وارد کردن عبارت عبور باز می‌شود.
5. شروع استخراج با miner.start(1) تا تراکنش استقرار در بلاکی قرار بگیرد؛ بدون ماینر در حال کار، قرارداد هرگز استقرار نمی‌یابد.
6. چسباندن اسکریپت در کنسول geth. لاگ گره پیام «Submitted contract creation» را با هش تراکنش و آدرس قرارداد نشان می‌دهد.
7. پس از استقرار، ویژگی‌های شیء قرارداد قابل پرس‌وجو است: valuechecker.address، valuechecker.transactionHash، valuechecker.abi و حتی eth.getBalance(valuechecker.address) که صفر است.

برای آزمایش منطق، تابع با valuechecker.Matcher.call(...) فراخوانی می‌شود. نتیجه: ورودی ۱۲ و ۱۰ هر دو true و ورودی ۹ برابر false است. نکتهٔ مفهومی: call یک اجرای محلی و فقط‌خواندنی است که تراکنش نمی‌سازد و گاز نمی‌سوزاند، در برابر ارسال یک تراکنش واقعی که وضعیت را تغییر می‌دهد.

درخواست‌های POST و JSON-RPC

به‌جای کنسول می‌توان از JSON-RPC روی HTTP و ابزار curl استفاده کرد (در صورتی که API مربوطه با --rpcapi فعال شده باشد). مثال کتاب: ارسال یک درخواست POST با بدنهٔ JSON شامل jsonrpc: "2.0"، method: "personal_listAccounts"، params: [] و id: 4 به localhost:8545 با هدر Content-Type: application/json. پاسخ یک شیء JSON با فیلد result است که آرایهٔ آدرس حساب‌ها را دارد. در دستور: --request نوع درخواست، --data بدنه و آخر آدرس نقطهٔ پایانی HTTP گره است.

فرانت‌اند HTML و JavaScript

برای تعامل کاربرپسند با قراردادها، صفحهٔ وب ساخته می‌شود: محتوای HTML را هر وب‌سرور ساده‌ای سرو می‌کند، و web3.js در مرورگر از طریق RPC محلی به کلاینت اتریوم (geth) وصل می‌شود. معماری: مرورگر ← web3.js ← گره اتریوم ← بلاک‌چین.

نصب web3.js و راه‌اندازی provider

• نصب با npm install web3 (یا دانلود از مخزن گیت‌هاب ethereum/web3.js)؛ فایل web3.js/web3.min.js زیر node_modules/web3/dist پیدا می‌شود و می‌توان آن را کنار برنامه کپی کرد.
• باید یک provider تعیین شود، معمولاً HttpProvider به نشانی http://localhost:8545.
• الگوی استاندارد ساخت شیء: اگر web3 از قبل تعریف شده بود (مثلاً توسط افزونه‌ای مثل کیف پول مرورگر)، از web3.currentProvider همان استفاده می‌شود؛ در غیر این صورت یک HttpProvider محلی ساخته می‌شود.

مثال: SimpleContract Interactor

مراحل پروژهٔ کوچک:

1. ساخت پوشه‌ای مثل simplecontract/app.
2. فایل app.js: ساخت شیء web3، تنظیم web3.eth.defaultAccount روی حساب اول، تعریف ABI (که از geth، کامپایلر solidity یا بخش details در Remix به دست می‌آید)، ساخت نمونهٔ قرارداد با SimpleContract.at(<آدرس قرارداد>) و چاپ آن با console.log به‌عنوان آزمون اتصال، و دو تابع callMatchertrue() (ورودی ثابت ۱۲) و callMatcherfalse() (ورودی ثابت ۱).
3. فایل index.html با دو دکمهٔ callTrue و callFalse که این توابع را صدا می‌زنند.

نویسنده عمداً از jQuery، React و Angular استفاده نمی‌کند، چون ربطی به اتریوم ندارند و تمرکز باید روی بلاک‌چین بماند، هرچند در عمل رایج‌اند. توصیه می‌شود صفحه از طریق وب‌سرور سرو شود، نه مستقیم از فایل‌سیستم؛ یک سرور سریع پایتون با python -m SimpleHTTPServer 7777 (پایتون ۲) کافی است. خروجی در کنسول مرورگر دیده می‌شود (Ctrl+Shift+J در ویندوز/لینوکس، Cmd+Option+J در مک). مقدارهای ثابت صرفاً برای نشان دادن این است که پارامتر از راه Web3 به قرارداد می‌رسد و مقدار بازگشتی برمی‌گردد.

فریم‌ورک‌های توسعه

استقرار دستی، همان‌طور که دیده شد، زمان‌بر است. فریم‌ورک‌هایی مانند Truffle و Embark این فرایند را ساده و سریع می‌کنند. نویسنده Truffle را برگزیده چون جامعهٔ توسعه‌دهندهٔ فعال‌تری دارد و در آن زمان پرکاربردترین فریم‌ورک اتریوم بود؛ البته تأکید می‌کند «بهترین» فریم‌ورک وجود ندارد و همه یک هدف دارند: آسان‌تر کردن توسعه، تست و استقرار.

Truffle

راه‌اندازی اولیه

با ساخت یک پوشه (مثلاً testdapp) و اجرای truffle init ساختار پروژه ایجاد می‌شود: سه پوشه (contracts، migrations، test) و چهار فایل (Migrations.sol، 1_initial_migration.js، truffle-config.js، truffle.js). دستورهای اصلی: truffle compile، truffle migrate، truffle test.

در نسخه‌های قدیمی‌تر truffle init پروژهٔ نمونهٔ MetaCoin می‌ساخت؛ اکنون این پروژه در قالب یک Truffle box عرضه می‌شود.

مثال MetaCoin با webpack box و Ganache

Ganache به‌عنوان بلاک‌چین محلی و ارائه‌دهندهٔ Web3 در پس‌زمینه اجرا می‌شود (در مثال: پورت ۷۵۴۵ و ۵ حساب؛ از بخش Settings قابل تغییر). مراحل:

1. truffle unbox webpack برای دانلود الگوی پروژه (دستورهای تکمیلی: npm run lint، npm run dev، npm run build).
2. ویرایش truffle.js تا شبکهٔ development به localhost و پورت ۷۵۴۵ با network_id: '*' (هر شناسه) اشاره کند.
3. truffle compile که سه قرارداد ConvertLib.sol، MetaCoin.sol و Migrations.sol را کامپایل و آرتیفکت‌ها را در ./build/contracts می‌نویسد.
4. ویرایش app/javascripts/app.js تا HttpProvider پیش‌فرض (پورت ۹۵۴۵) به http://127.0.0.1:7545 تغییر کند.
5. truffle test: پنج تست موفق، از جمله دو تست Solidity (testInitialBalanceUsingDeployedContract و testInitialBalanceWithNewMetaCoin) و سه تست JavaScript (قرار گرفتن ۱۰٬۰۰۰ MetaCoin در حساب اول، تابعی وابسته به کتابخانهٔ لینک‌شده، و ارسال درست سکه).
6. truffle migrate: قراردادها روی Ganache مستقر می‌شوند. در رابط Ganache تراکنش‌ها دیده می‌شوند و موجودی اتر حساب‌ها به‌دلیل هزینهٔ گاز کم می‌شود؛ حساب نمایش‌داده‌شده با حساب Truffle یکی است.
7. npm run dev سرور توسعه (webpack) را بالا می‌آورد.
8. مرورگر روی http://localhost:8080 فرانت‌اند MetaCoin را نشان می‌دهد که با آن می‌توان سکه را به حساب‌های دیگر فرستاد؛ این تراکنش‌ها هم در Ganache ظاهر می‌شوند.

کنسول Truffle

truffle console یک رابط خط فرمان از نوع REPL (Read-Evaluate-Print Loop) است؛ مشابه کنسول geth که از JSRE (محیط اجرای JavaScript) استفاده می‌کند. قراردادهای مستقرشده از پیش در آن نمونه‌سازی شده‌اند و با Tab می‌توان متدها را دید. مثال‌ها: MetaCoin.address (که با آدرس تراکنش ساخت قرارداد در Ganache یکی است)، web3.eth.accounts[0] (آدرس حساب اول Ganache که با 0x627306… شروع می‌شود) و MetaCoin.web3.eth.getBalance(...) که موجودی را به‌شکل عدد بزرگ (BigNumber) به wei برمی‌گرداند. خروج با .exit.

مثال دوم: قرارداد Addition

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

• Addition.sol: متغیر uint8 x، تابع addx(y, z) که مجموع را در x می‌نویسد و تابع retrievex() از نوع constant که مقدار را برمی‌گرداند.
• Migrations.sol: قرارداد استاندارد Truffle که مالک را نگه می‌دارد، آخرین مهاجرت انجام‌شده را در last_completed_migration ثبت می‌کند و دسترسی به setCompleted و upgrade را با modifier به نام restricted به مالک محدود می‌کند.
• در migrations/ دو اسکریپت: 1_initial_migration.js (استقرار Migrations) و 2_deploy_contracts.js (استقرار Addition با deployer.deploy).
• در test/ فایل Solidity به نام TestAddition.sol که با truffle/Assert.sol و DeployedAddresses.sol نمونهٔ مستقرشده را می‌گیرد، addx(100,100) را صدا می‌زند و با Assert.equal انتظار ۲۰۰ دارد.

سپس در truffle console می‌توان Addition.address را دید و توابع را روی نمونهٔ مستقرشده فراخوانی کرد.

پروژهٔ نمونه: PatentIdea (اثبات ایده)

ایده

سرویسی برای سندنگاری (notarization): نشان دادن اینکه شخص در لحظه‌ای مشخص به یک اطلاعات (مثلاً سند ثبت اختراع) دسترسی داشته است. صاحب ایده هش سند را می‌سازد و روی بلاک‌چین ذخیره می‌کند؛ به‌دلیل تغییرناپذیری بلاک‌چین، این یک شاهد دائمی است که آن سند در آن زمان وجود داشته. اصل کار بر این است که تابع هش یک چکیدهٔ یکتا از متن می‌دهد. اگر هش همان متن قبلاً ذخیره شده باشد، ثبت دوباره رد می‌شود. ابزارها: Remix (browser solidity)، Truffle و شبکهٔ آزمایشی با شناسهٔ ۷۸۶.

توضیح قرارداد خط‌به‌خط

• pragma solidity ^0.4.0 حداقل نسخهٔ کامپایلر را مشخص می‌کند (کتاب می‌گوید سقف آن زیر ۰٫۵ است).
• قرارداد PatentIdea یک mapping(bytes32 => bool) private hashes دارد (جدول هش از هش به بولین)، متغیر بولین alreadyStored برای نگه‌داری نتیجهٔ ثبت، و رویداد ideahashed(bool) برای اعلام موفقیت/شکست.
• saveHash(bytes32) از نوع private است و هش را در map برابر true می‌گذارد (تغییر وضعیت).
• SaveIdeaHash(string idea) تابع عمومی ثبت است: هش را حساب می‌کند؛ اگر قبلاً وجود داشت رویداد را با false صادر و alreadyStored را برمی‌گرداند؛ وگرنه ذخیره می‌کند و رویداد true می‌دهد.
• alreadyHashed(bytes32) (constant و private) صرفاً map را می‌خواند.
• isAlreadyHashed(string idea) (constant و public) رابط پرس‌وجوی بیرونی است و بدون تغییر وضعیت می‌گوید آیا ایده قبلاً ثبت شده یا نه.
• HashtheIdea(string) (constant و private) از sha3 استفاده می‌کند که در Solidity مترادف keccak256() است.

نکتهٔ مهم: sha3 در Solidity همان SHA-3 استاندارد NIST نیست، بلکه Keccak-256 است؛ یعنی نسخهٔ اصلی پیشنهادی در مسابقهٔ NIST، که بعدها اندکی تغییر کرد و استاندارد شد. بنابراین خروجی SHA-3 رسمی با sha3 اتریوم متفاوت است. نویسنده خودش اذعان می‌کند که کد ساده نگه داشته شده و می‌توان آن را بهبود داد؛ مثلاً تاریخ را هم در map کنار هش ذخیره کرد یا ساختارهای داده‌ای با اطلاعات بیشتر درباره پتنت اضافه کرد.

شبیه‌سازی در Remix با Ganache

پس از تایپ کد و تأیید نحو، با کلیک روی Create دو تابع SaveIdeaHash و isAlreadyHashed در پنل سمت راست نمایان می‌شوند. لاگ‌های Remix برای هر تراکنش این اطلاعات را نشان می‌دهند:

اگر همان رشته دوباره ارسال شود ذخیره نمی‌شود: رویداد false برمی‌گرداند و مقدار بازگشتی تابع true است که یعنی هش از قبل وجود داشته. همهٔ تراکنش‌های صادرشده از Remix در رابط Ganache هم دیده می‌شوند.

استقرار روی شبکهٔ خصوصی ۷۸۶ با Truffle

1. ساخت پوشهٔ ideapatent و truffle init.
2. قرار دادن PatentIdea.sol در contracts/.
3. ویرایش truffle.js: host: 'localhost'، port: 8545، network_id: 786.
4. ساخت migrations/2_deploy_contracts.js با artifacts.require("PatentIdea") و deployer.deploy.
5. truffle compile.
6. با ماینر فعال، truffle migrate؛ خروجی هش تراکنش و آدرس برای Migrations و PatentIdea را نشان می‌دهد.
7. truffle console، سپس PatentIdea.deployed().then(function(instance){app = instance}) و فراخوانی app.SaveIdeaHash("hello1"). اگر حساب قفل باشد با personal.unlockAccount(web3.eth.coinbase, <رمز>, 15000) باز می‌شود (آخرین پارامتر مدت باز ماندن بر حسب ثانیه است).
8. بررسی: app.isAlreadyHashed("hello1") مقدار true و app.isAlreadyHashed("hello3") مقدار false می‌دهد.

برای TestNet یا شبکهٔ اصلی کافی است RPC مناسب تنظیم و باز هم truffle migrate اجرا شود.

اوراکل‌ها (Oracles)

همان‌طور که در فصل ۹ آمد، اوراکل منبع داده‌های دنیای واقعی برای قراردادهای هوشمند است (قیمت زنده، آب‌وهوای یک شهر و غیره)، چون قرارداد خودش نمی‌تواند به اینترنت دسترسی داشته باشد. سرویس برجستهٔ آن زمان Oraclize بود (oraclize.it). مکانیسم کار:

• قرارداد کاربر یک تراکنش به قرارداد Oraclize می‌فرستد که شامل پرداخت و پرس‌وجو است.
• Oraclize داده را از منبع بیرونی می‌گیرد و پاسخ را به آدرس قرارداد برمی‌گرداند؛ در این لحظه تابع callback (یا fallback) قرارداد فراخوانی می‌شود.
• پاسخ همراه با TLSNotary proof می‌آید که اصالت و یکپارچگی پیام را اثبات می‌کند (اثبات رمزنگاری‌شدهٔ ارتباط بین دو طرف).
• در Solidity کافی است کتابخانهٔ Oraclize ایمپورت و قرارداد از usingOraclize ارث‌بری شود؛ نمونهٔ پرس‌وجو: oraclize_query("URL", "api.somewebsite.net/price?stock=XYZ").
• در آن زمان فقط روی شبکهٔ آزمایشی Ropsten و شبکهٔ اصلی اتریوم قابل استفاده بود (کتاب این را «PrivateNet (Ropsten)» می‌نامد)، و ایمپورت dev.oraclize.it/api.sol فقط در محیط توسعهٔ آنلاین خودشان کار می‌کند و در غیر آن باید فایل را دستی وارد کرد.

استقرار روی ذخیره‌سازی غیرمتمرکز با IPFS

برای بهره‌مندی کامل از پلتفرم‌های غیرمتمرکز، لایهٔ ذخیره‌سازی و ارتباطات هم باید غیرمتمرکز شود، نه فقط وضعیت/محاسبه (بلاک‌چین). محتوای وب معمولاً از سرورهای متمرکز می‌آید، ولی می‌توان آن را روی فایل‌سیستم توزیع‌شده مثل IPFS (InterPlanetary File System، ipfs.io) گذاشت.

مراحل نصب و استفاده (نسخهٔ go-ipfs v0.4.4 روی لینوکس):

1. دانلود بستهٔ tar.gz با curl، باز کردن با tar xvfz، و جابه‌جایی فایل اجرایی به /usr/local/bin.
2. ipfs init که یک گرهٔ IPFS می‌سازد، جفت‌کلید RSA ۲۰۴۸ بیتی تولید می‌کند و یک peer identity (شناسهٔ ‏Qm…) می‌دهد.
3. ipfs daemon: گوش دادن روی پورت swarm ‏4001، سرور API روی ۵۰۰۱ و gateway فقط‌خواندنی روی ۸۰۸۰.
4. افزودن پوشهٔ build برنامهٔ dapp با ipfs add --recursive؛ هر فایل و پوشه یک هش محتوا (Qm…) می‌گیرد و هش پوشهٔ ریشه نشانی برنامه است.
5. دسترسی از مرورگر با آدرس gateway که مسیر /ipfs/<هش> دارد.
6. برای ماندگار کردن محتوا (جلوگیری از garbage collection) از ipfs pin add <هش> استفاده می‌شود.

دو کاربرد IPFS در کنار بلاک‌چین: (۱) میزبانی رابط کاربری dapp؛ (۲) ذخیرهٔ داده‌های حجیم خارج از زنجیره و نگه‌داشتن فقط پیوند (هش IPFS) در تراکنش، تا بلاک‌چین متورم نشود، چون ذخیره‌سازی روی زنجیره یکی از گلوگاه‌های بزرگ است.

Swarm و Whisper

• Swarm راه‌حل ذخیره‌سازی بومی اتریوم با اصول مشابه است. برای استفاده باید یک گرهٔ Swarm (نیازمند geth و کلاینت Swarm) اجرا شود و از API روی HTTP استفاده کرد. پروتکل آن bzz است؛ هر گره با bzzkey شناخته می‌شود که از هش Keccak-256 آدرس coinbase گره geth مشتق می‌شود. داده در Swarm از chunkها (حداکثر ۴ کیلوبایت)، hash (مشتق از خود داده، شناسهٔ chunk) و manifest (توصیف نحوهٔ دسترسی و ذخیره: هش‌ها، ایندکس‌ها و مسیر دایرکتوری برای بازیابی با URL) تشکیل می‌شود.
• Whisper لایهٔ ارتباط (پیام‌رسانی) غیرمتمرکز مبتنی بر هویت برای اتریوم است.
• نویسنده هر دو را فناوری‌های توانمندساز «وب ۳٫۰» می‌داند.

دفترهای کل توزیع‌شده (Distributed Ledgers)

مفهوم دفتر کل توزیع‌شدهٔ مجوزدار (permissioned) اساساً با بلاک‌چین عمومی تفاوت دارد:

• همهٔ شرکت‌کنندگان از قبل شناخته و بررسی‌شده‌اند، پس به ماینینگ برای امن‌سازی شبکه نیازی نیست.
• ارز دیجیتال در آن‌ها معنا ندارد، چون هدفشان با بلاک‌چین عمومی فرق دارد.
• بلاک‌چین عمومی برای رشد به انگیزه (incentive) و اثر شبکه‌ای نیاز دارد؛ DLT مجوزدار چنین نیازی ندارد.
• می‌توان DLT مجوزدار را بر پایهٔ اتریوم در محیط کنسرسیومی خصوصی ساخت، به‌ویژه برای کار در چارچوب سیستم‌های مالی موجود.
• مزیت‌های کلیدی: سرعت بسیار بیشتر، قابلیت حاکمیت (governability) و احتمال سازگاری با سیستم مالی کنونی.

فصل بعد (Hyperledger) همین مسیر را ادامه می‌دهد.

جمع‌بندی

• Web3 کتابخانهٔ JavaScript برای صحبت با گره اتریوم از راه RPC است؛ با geth (سوئیچ‌های --rpc و --rpcapi و CORS) یا از طریق JSON-RPC روی HTTP با curl قابل استفاده است.
• استقرار دستی یک قرارداد شامل گرفتن ABI و بایت‌کد از Remix، باز کردن حساب، روشن کردن ماینر و اجرای اسکریپت در کنسول geth است؛ فراخوانی call محلی و بدون هزینه است.
• یک dapp ساده از app.js (شیء web3، ABI، نمونهٔ قرارداد) و یک index.html تشکیل می‌شود که با وب‌سرور سرو می‌شود.
• Truffle با ساختار contracts/migrations/test و دستورهای compile، migrate، test و console چرخهٔ توسعه را خودکار می‌کند؛ Ganache هم بلاک‌چین محلی سریع و رابط تصویری برای دیدن تراکنش‌ها و موجودی‌ها فراهم می‌کند.
• پروژهٔ PatentIdea نشان داد چگونه از ایده تا کد، شبیه‌سازی در Remix و استقرار روی شبکهٔ خصوصی ۷۸۶، یک سرویس اثبات وجود سند با هش Keccak-256 ساخته می‌شود (و اینکه sha3 اتریوم با SHA-3 استاندارد فرق دارد).
• اوراکل‌ها مثل Oraclize با TLSNotary داده‌های بیرونی را قابل اعتماد به قرارداد می‌رسانند؛ IPFS، Swarm و Whisper لایه‌های ذخیره‌سازی و ارتباطات غیرمتمرکز را تکمیل می‌کنند.
• در نهایت، دفترهای کل مجوزدار بدون ماینینگ و ارز، سریع‌تر و حاکمیت‌پذیرترند و زمینهٔ ورود به فصل Hyperledger هستند.

فصل ۱۵ — هایپرلجر (Hyperledger)

مقدمه: هایپرلجر چیست و چه نیست

• هایپرلجر (Hyperledger) خودش یک بلاک‌چین نیست؛ یک پروژهٔ چتری متن‌باز است که بنیاد لینوکس (Linux Foundation) در دسامبر ۲۰۱۵ راه انداخت تا فناوری بلاک‌چین را پیش ببرد. هدف، ساخت چارچوب‌های دفتر کل توزیع‌شده (distributed ledger) برای کاربردهای میان‌صنعتی و تراکنش‌های تجاری جهانی است، با تمرکز بر قابلیت اطمینان و کارایی سامانه‌ها.
• پروژه‌ها چرخهٔ عمر مشخصی دارند: پیشنهاد (proposal) ← نهادینه‌سازی/انکوباسیون (incubation) ← فعال (active)؛ و در پایان ممکن است منسوخ (deprecated) یا در وضعیت پایان عمر (end-of-life) قرار گیرند. شرط ورود به انکوباسیون داشتن کد کاملاً کارا و جامعهٔ توسعه‌دهندهٔ فعال است.
• در زمان نگارش کتاب بیش از ۲۰۰ سازمان عضو بودند و رویدادها و ارائه‌های منظمی در سراسر جهان برگزار می‌شد.
• فصل ابتدا همهٔ پروژه‌ها را معرفی می‌کند، سپس معماری مرجع و الزامات طراحی را می‌آورد و آنگاه Fabric و Sawtooth Lake را عمیق‌تر بررسی می‌کند و در پایان به Corda می‌رسد (که رسماً پروژهٔ هایپرلجر نیست ولی در همین فصل آمده است).

پروژه‌های زیر چتر هایپرلجر

پروژه‌ها دو دسته‌اند: چارچوب‌های بلاک‌چین (پنج مورد) و ابزارها/ماژول‌های پشتیبان (چهار مورد).

چارچوب‌های بلاک‌چین

ابزارها و ماژول‌ها

• Explorer: کاوشگر بلاک‌چین برای Fabric؛ مشاهده و پرسوجوی تراکنش‌ها، بلاک‌ها و داده‌های مرتبط، اطلاعات شبکه و امکان تعامل با chaincode.
• Cello: استقرار آسان بلاک‌چین و ارائهٔ آن به‌صورت «سرویس» (as a service).
• Composer: توصیف فرایندهای کسب‌وکار به زبان کسب‌وکار و پنهان‌کردن جزئیات سطح پایین توسعهٔ قرارداد هوشمند.
• Quilt: پیاده‌سازی پروتکل Interledger برای تعامل‌پذیری میان شبکه‌های دفتر کلِ توزیع‌شده و غیرتوزیع‌شده.

همهٔ این‌ها در مراحل مختلف توسعه بودند و انتظار می‌رفت فهرست با پیوستن اعضای جدید بلندتر شود.

هایپرلجر به‌مثابه پروتکل

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

معماری مرجع

هایپرلجر یک کاغذ سفید منتشر کرده که معماری مرجعی برای ساخت دفاتر کل مجوزدار (permissioned) ارائه می‌دهد. این معماری پنج جزء سطح بالا دارد:

1. هویت (identity): خدمات احراز هویت، تشخیص هویت و مجوزدهی در قالب خدمات عضویت.
2. سیاست (policy): خدمات مدیریت سیاست‌ها.
3. دفتر کل و تراکنش‌ها: شامل دفتر کل توزیع‌شده، سرویس ترتیب‌دهی (ordering)، پروتکل‌های شبکه و خدمات تأیید (endorsement) و اعتبارسنجی؛ این دفتر فقط با اجماع شرکت‌کنندگان تغییر می‌کند.
4. قرارداد هوشمند: سرویس chaincode که قراردادها را در کانتینر امن میزبانی می‌کند.

از منظر لایه‌ها، اجزای معماری این‌هاست:

• لایهٔ اجماع: توافق بر ترتیب و وضعیت تراکنش‌ها.
• لایهٔ قرارداد هوشمند: پیاده‌سازی منطق کسب‌وکار؛ تراکنش‌ها بر اساس منطق قراردادهای ثبت‌شده روی زنجیره پردازش می‌شوند.
• لایهٔ ارتباطات: انتقال و تبادل پیام بین گره‌ها.
• لایهٔ امنیت و رمزنگاری: امکان استفاده از الگوریتم‌ها/ماژول‌های رمزنگاری گوناگون برای حریم خصوصی، محرمانگی و عدم انکار (non-repudiation).
• ذخیره‌سازی داده: مخزن وضعیت دفتر کل نیز قابل‌اتصال است و هر پایگاه دادهٔ پشتیبانی را می‌پذیرد.
• خدمات سیاست: مدیریت سیاست‌های شبکه، از جمله سیاست تأیید و سیاست اجماع.
• API و SDK: تعامل کلاینت‌ها و برنامه‌ها؛ SDK برای استقرار و اجرای chaincode، پرسوجوی بلاک‌ها و پایش رویدادها.

الزامات و اهداف طراحی Hyperledger Fabric

این الزامات از مطالعهٔ کاربردهای صنعتی و نیاز اعضای پروژه استخراج شده‌اند:

• رویکرد ماژولار: ذخیره‌سازی، سیاست، chaincode، کنترل دسترسی، اجماع و غیره باید plug-and-play باشند تا کاربر بتواند ماژول مناسب کسب‌وکارش را اضافه یا حذف کند.
• حریم خصوصی و محرمانگی: در شبکهٔ مجوزدار فقط افراد مجاز باید تراکنش‌ها را ببینند. هایپرلجر می‌خواهد دامنهٔ کاملی از پروتکل‌های رمزنگاری را پشتیبانی کند. اگر طرف‌ها از قبل به هم اعتماد دارند و عملیات ساده است، شاید رمزنگاری پیشرفته لازم نباشد و ماژول قابل‌حذف است؛ در شبکهٔ میان‌صنعتی برعکس، رمزنگاری و کنترل دسترسی پیشرفته (حتی HSM، ماژول امنیت سخت‌افزاری) باید قابل‌اتصال باشد، بی‌آنکه کارایی فدا شود. همچنین باید بتوان سیاست‌های حریم خصوصی مطابق مقررات و انطباق (compliance) پیاده کرد.
• مقیاس‌پذیری: توان عملیاتی کافی برای نیازهای تجاری و تعداد زیاد کاربران.
• قطعیت (determinism) تراکنش‌ها: اگر اجرای یک تراکنش بسته به اجراکننده یا مکان نتایج متفاوت بدهد، اجماع ناممکن است (مباحث فصل ۹).
• هویت: مدل PKI انعطاف‌پذیر برای کنترل دسترسی، با قدرت و نوع رمزنگاری قابل‌تنظیم؛ در برخی سناریوها کاربر باید بتواند هویتش را پنهان کند.
• قابلیت ممیزی (auditability): ردّ ممیزی تغییرناپذیر از هویت‌ها، عملیات و تغییرات.
• تعامل‌پذیری (interoperability): استانداردهای مشترک تا بلاک‌چین‌های مختلف بتوانند با هم ارتباط بگیرند و پروتکلی برای تبادل اطلاعات میان fabricها پدید آید.
• قابلیت حمل (portability): اجرا روی پلتفرم‌های مختلف بدون تغییر کد، هم در سطح زیرساخت و هم در سطح کد، کتابخانه و API.
• پرسوجوهای غنی: پرسوجوی وضعیت فعلی دفتر کل با زبان‌های پرسوجوی آشنا برای پذیرش گسترده‌تر.

Fabric: واژگان و مفهوم

• Fabric (در معنای عام) مجموعه‌ای از اجزاست که لایهٔ پایه‌ای یک شبکهٔ بلاک‌چین را فراهم می‌کند. همهٔ fabricها ویژگی‌هایی مشترک مثل تغییرناپذیری و اجماع‌محوری دارند؛ بعضی ماژولار هستند (مثلاً الگوریتم اجماع قابل‌تعویض) و می‌توانند خصوصی یا عمومی باشند و چند شبکهٔ تجاری بسازند. مثلاً بیت‌کوین برنامه‌ای است که روی fabric خودش (شبکهٔ بلاک‌چین) اجرا می‌شود.
• Hyperledger Fabric نام کدی است که IBM (و DAH) به بنیاد هدیه کرد و هدفش ساخت یک دفتر کل توزیع‌شدهٔ مجوزدار است. IBM همچنین «بلاک‌چین به‌عنوان سرویس» را روی IBM Cloud عرضه می‌کند.

ویژگی‌های اصلی

• توابع مختلف قابل‌اتصال‌اند و برای نوشتن قرارداد هوشمند می‌توان از زبان‌های مختلف استفاده کرد، چون پایه‌اش فناوری کانتینر (Docker) است.
• قرارداد هوشمند در Fabric chaincode نام دارد و در کانتینر امن (شامل سیستم‌عامل امن، زبان، محیط اجرا و SDKهایی برای Go، Java و Node.js) در حالت sandbox اجرا می‌شود؛ این در مقایسه با زبان‌های دامنه‌محور اتریوم یا اسکریپت محدود بیت‌کوین مزیتی جذاب است.
• هدف‌ها: مقیاس‌پذیری، حریم خصوصی و محرمانگی از راه ماژولار‌بودن و امکان تنظیم دقیق هر ویژگی.
• تراکنش‌ها برای کاربران عادی خصوصی، محرمانه و ناشناس‌اند اما ممیزان مجاز می‌توانند آن‌ها را ردیابی و به کاربران ربط دهند. همهٔ شرکت‌کنندگان باید نزد خدمات عضویت ثبت‌نام کنند.

خدمات عضویت (Membership Services)

• وظایف: تأیید هویت کاربر، ثبت‌نام کاربر، و اعطای مجوز مناسب بر اساس نقش.
• مبتنی بر مرجع صدور گواهی (CA): یا CA داخلی (Fabric CA، پیش‌فرض) یا CA خارجی.
• Fabric CA گواهی‌های ثبت‌نام (E-Cert) را از طریق E-CA صادر می‌کند؛ پس از دریافت هویت، peer اجازهٔ پیوستن به شبکه را دارد. گواهی‌های موقت (T-Cert) برای تراکنش‌های یک‌بارمصرف نیز وجود دارند.
• همهٔ peerها و برنامه‌ها با CA شناسایی می‌شوند؛ MSP می‌تواند با سرویس‌های هویت موجود مثل LDAP رابط شود.

خدمات بلاک‌چین (Blockchain Services)

خدمات اجماع

ماژولی قابل‌اتصال که تراکنش‌ها را از دیگر موجودیت‌ها می‌گیرد و بر اساس سازوکار انتخابی اجرا می‌کند. در Fabric نسخهٔ ۱، اجماع به‌صورت یک peer ویژه به نام orderer پیاده شده که تراکنش‌ها را به ترتیب در بلاک می‌چیند و خودش قرارداد یا دفتر کل ندارد. دو سرویس ترتیب‌دهی موجود بود:

• SOLO: ساده، برای توسعه و آزمایش.
• Kafka: مبتنی بر Apache Kafka؛ فقط تحمل خرابی از نوع crash را دارد و تحمل خطای بیزانسی ندارد که در شبکهٔ مجوزدار با بازیگر مخرب نادر قابل‌قبول است.

مکانیزم مبتنی بر SBFT (Simple BFT) در دست توسعه بود.

دفتر کل توزیع‌شده

دو عنصر اصلی: بلاک‌چین (فهرست پیوندی رمزنگاری‌شدهٔ بلاک‌ها) و world state (پایگاه داده کلید-مقدار که قراردادها حین اجرا وضعیت‌ها را در آن نگه می‌دارند). هر گره world state را روی دیسک در LevelDB یا CouchDB ذخیره می‌کند؛ مخزن داده قابل‌تعویض است.

ساختار بلاک در Fabric 1.0 سه بخش دارد:

• سرآیند بلاک (Header): شمارهٔ بلاک، هش قبلی، هش داده.
• تراکنش‌ها (Data): هر تراکنش فیلدهای فراوانی دارد: نوع، نسخه، زمان، شناسهٔ کانال، شناسهٔ تراکنش، epoch، مسیر/نام/نسخه/نوع chaincode، هویت سازنده و امضا، ورودی، timeout، هویت و امضای endorserها، هش proposal، رویدادهای chaincode، وضعیت پاسخ، namespace، read set و write set و خلاصهٔ درخت Merkle برای پرسوجوها.
• فراداده (Metadata): هویت سازنده و امضاها، شمارهٔ آخرین بلاک پیکربندی، پرچم اعتبار برای هر تراکنش، و آخرین offset ذخیره‌شده (برای Kafka).

پروتکل نظیر-به-نظیر

مبتنی بر gRPC (گوگل) و protocol buffers برای تعریف ساختار پیام. چهار نوع پیام: discovery (کشف همتایان هنگام راه‌اندازی)، transaction (استقرار، فراخوانی و پرسوجو)، synchronization (همگام‌سازی بلاک‌چین بین گره‌ها) و consensus.

ذخیره‌سازی دفتر کل

پیش‌فرض LevelDB روی هر peer؛ جایگزین CouchDB که پرسوجوی غنی امکان‌پذیر می‌کند.

خدمات chaincode

• کانتینر امن: chaincode در Docker با محیط قفل‌شدهٔ sandbox اجرا می‌شود؛ زبان اصلی Go است و زبان‌های دیگر قابل‌افزودن‌اند.
• رجیستری امن: ثبت همهٔ imageهای حاوی قراردادهای هوشمند.

رویدادها و API/CLI

رویدادها را endorserها و قراردادها می‌توانند ایجاد کنند و برنامه‌های بیرونی از راه event adapter به آن‌ها گوش می‌دهند (شبیه events در Solidity، فصل ۱۴). API از نوع REST است و CLIها زیرمجموعه‌ای از آن را برای آزمون سریع ارائه می‌کنند.

اجزای Fabric

اجزا شامل دفتر کل، chaincode، اجماع، کنترل دسترسی، رویدادها، پایش و مدیریت سامانه، کیف پول‌ها و ادغام سامانه‌ها هستند.

• Peers: نگهدارندهٔ نسخهٔ محلی دفتر کل که با پروتکل gossip ارتباط می‌گیرند. سه نوع:
  • Endorsing peer (endorser): اجرای شبیه‌سازی‌شدهٔ تراکنش و تولید read-write set (خواندن‌ها و به‌روزرسانی‌هایی که در صورت اجرای واقعی رخ می‌داد). هر endorser در عین حال committer هم هست. سیاست‌های تأیید (endorsement policies) با chaincode پیاده می‌شوند و قواعد تأیید تراکنش را معین می‌کنند.
  • Committing peer (committer): دریافت تراکنش‌های تأییدشده، بررسی read-write set و اعتبار تراکنش، و سپس به‌روزرسانی دفتر کل.
  • Submitter: نوع سوم که هنوز پیاده نشده بود.
• Orderer nodes: تراکنش‌ها را به‌همراه read-write set از endorserها می‌گیرند، مرتب می‌کنند و برای committerها می‌فرستند. همهٔ peerها گواهی‌های صادرشده توسط خدمات عضویت را به کار می‌برند.
• Clients: نرم‌افزارهایی که با API به Fabric وصل می‌شوند و تراکنش پیشنهاد می‌دهند.
• Channels: امکان جریان تراکنش‌های محرمانه بین طرف‌های معین روی همان شبکه، اما با بلاک‌چین‌های جداگانه؛ فقط اعضای کانال تراکنش‌های آن را می‌بینند.
• World state database: نمایانگر همهٔ تراکنش‌های ثبت‌شده؛ LevelDB (کلید-مقدار) یا CouchDB (اشیای JSON با پرسوجوی غنی).
• تراکنش‌ها: دو نوع استقرار (deployment: نصب chaincode) و فراخوانی (invocation: صدا زدن توابع قرارداد). می‌توانند عمومی (دیدنی برای همه) یا محرمانه (فقط برای شرکت‌کنندگان کانال) باشند.
• MSP (Membership Service Provider): مؤلفهٔ ماژولار مدیریت هویت و احراز هویت کلاینت‌های متقاضی ورود؛ CA برای تأیید و الصاق هویت در آن به کار می‌رود.
• قراردادهای هوشمند (chaincode): شامل شرایط و پارامترهای اجرای تراکنش و به‌روزرسانی دفتر کل؛ معمولاً با Go یا Java.
• Crypto service provider: ارائهٔ الگوریتم‌ها و استانداردهای رمزنگاری: مدیریت کلید، امضا و تأیید، رمزگذاری/رمزگشایی؛ همراه خدمات عضویت برای endorser، کلاینت و peerها.

برنامه‌ها روی Fabric

یک برنامهٔ معمول از رابط کاربری (غالباً JavaScript/HTML) تشکیل شده که از طریق لایهٔ API با chaincode ذخیره‌شده روی دفتر کل کار می‌کند. APIها حوزه‌هایی چون هویت، تراکنش، chaincode، دفتر کل، شبکه، ذخیره‌سازی و رویدادها را پوشش می‌دهند.

پیاده‌سازی chaincode

chaincode معمولاً با Go یا Java نوشته می‌شود و می‌تواند عمومی، محرمانه یا دارای کنترل دسترسی باشد. توابعی که وضعیت را تغییر می‌دهند دفتر کل را به‌روز می‌کنند و توابع فقط‌پرسوجو هیچ تغییری نمی‌دهند. پیاده‌سازی با ساخت رابط shim شروع می‌شود که API دسترسی به متغیرهای وضعیت و زمینهٔ تراکنش را می‌دهد. چهار تابع لازم است:

• Init(): هنگام استقرار chaincode روی دفتر کل فراخوانی می‌شود، آن را مقداردهی اولیه می‌کند و وضعیت را تغییر می‌دهد.
• Invoke(): هنگام اجرای قرارداد؛ نام تابع و آرایهٔ آرگومان‌ها را می‌گیرد و روی دفتر کل می‌نویسد.
• Query(): خواندن وضعیت فعلی قرارداد مستقر؛ بدون تغییر دفتر کل.
• تابع چهارم (در متن کتاب نامش افتاده): هنگامی اجرا می‌شود که یک peer نسخهٔ خودش از chaincode را مستقر می‌کند و chaincode را نزد آن peer ثبت می‌کند.

نمودار کلی کتاب نشان می‌دهد peerها (شامل انواع endorser، committer و orderer) با هم و با خدمات عضویت (CA) کار می‌کنند، و سامانه‌های موجود می‌توانند رویداد تولید کنند یا به رویدادها گوش دهند و کاربر از راه برنامه، متدی از قرارداد (مثلاً invoice()) را صدا می‌زند که وضعیت بلاک‌چین را می‌خواند یا به‌روز می‌کند.

مدل برنامه (MVC-B)

برنامه‌های Fabric از الگوی MVC-B پیروی می‌کنند (مدل، نما، کنترل، بلاک‌چین): منطق نما (UI دسکتاپ/وب/موبایل)، منطق کنترل (هماهنگ‌کنندهٔ رابط کاربری، مدل داده و APIها)، مدل داده (مدیریت داده‌های خارج از زنجیره) و منطق بلاک‌چین (مدیریت بلاک‌چین از طریق کنترلر و مدل داده با تراکنش). IBM Cloud نمونه برنامه‌هایی برای آشنایی و ساخت شبکهٔ آزمایشی ارائه می‌کند.

اجماع در Fabric

اجماع در سه گام انجام می‌شود:

1. تأیید تراکنش (endorsement): با شبیه‌سازی اجرا.
2. ترتیب‌دهی (ordering): خوشهٔ orderها تراکنش‌های تأییدشده را به ترتیبی مشخص برای نوشتن در دفتر کل درمی‌آورند.
3. اعتبارسنجی و ثبت (validation & commitment): committing peerها ابتدا اعتبار را می‌سنجند و سپس ثبت می‌کنند.

چرخهٔ عمر تراکنش (۹ گام)

1. کلاینت (ثبت‌نام‌شده در خدمات عضویت) تراکنش را پیشنهاد می‌دهد و از طریق SDK به endorserها می‌فرستد.
2. endorserها chaincode را شبیه‌سازی می‌کنند و به‌جای به‌روزرسانی دفتر کل فقط RW set می‌سازند.
3. تراکنش تأییدشده به برنامه بازمی‌گردد.
4. برنامه تراکنش‌های تأییدشده و RW setها را به سرویس ترتیب‌دهی می‌فرستد.
5. سرویس ترتیب‌دهی آن‌ها را به‌ترتیب در بلاک جمع می‌کند و بر حسب شناسهٔ کانال دسته‌بندی می‌کند.
6. بلاک را برای همهٔ committing peerها پخش می‌کند.
7. committerها تراکنش‌ها را اعتبارسنجی می‌کنند.
8. دفتر کل را به‌روز می‌کنند.
9. موفقیت یا شکست به کلاینت/برنامه اطلاع داده می‌شود.

Sawtooth Lake

Sawtooth Lake می‌تواند در حالت مجوزدار و بدون مجوز کار کند و دو ایدهٔ نو دارد: الگوریتم اجماع PoET و خانواده‌های تراکنش (transaction families).

PoET (اثبات زمان سپری‌شده)

• گره بر اساس مدت زمانی که منتظر مانده تا پیشنهاد بلاک بدهد، به‌صورت تصادفی انتخاب می‌شود. این برخلاف PoW بیت‌کوین است که برای رسیدن به نقش پیشنهاددهندهٔ بلاک برق و منابع محاسباتی عظیمی مصرف می‌کند.
• PoET نوعی اثبات کار است که به‌جای صرف منابع محاسباتی از مدل محاسبات مورد اعتماد استفاده می‌کند: معماری Intel SGX یک محیط اجرای مورد اعتماد (TEE) فراهم می‌کند تا تصادفی‌بودن و امنیت رمزنگاری فرایند تضمین شود. ایدهٔ بنیادی: انتظار تصادفی برای انتخاب شدن به‌عنوان رهبر.
• پیاده‌سازی فعلی Sawtooth به SGX سخت‌افزاری واقعی نیاز نداشت و آن را فقط برای آزمایش شبیه‌سازی می‌کرد؛ پس برای تولید (production) مناسب نبود.
• محدودیتی که Ittay Eyal مطرح کرد، مسئلهٔ تراشه‌های کهنه (stale chips) است: هدررفت سخت‌افزار و منابع، و امکان هک سخت‌افزار تراشه که می‌تواند سامانه را به خطر بیندازد و مشوق‌های ناعادلانه برای ماینرها بسازد.

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

• در پارادایم سنتی قرارداد هوشمند (مثل EVM اتریوم) یک مجموعه‌دستورالعمل همه‌منظوره برای همهٔ حوزه‌ها وجود دارد. این یک رابط واحد و قدرتمند به دفتر کل می‌دهد که سطح حملهٔ بزرگ‌تری دارد؛ نمونه‌ها: هک DAO و حملات DoS که از محدودیت‌های برخی opcodeهای EVM بهره بردند (فصل ۹).
• راه‌حل Sawtooth: لایهٔ منطق به مجموعه‌ای از قواعد و لایهٔ ترکیب برای هر حوزهٔ خاص تفکیک می‌شود. خانوادهٔ تراکنش ترکیبی از مدل داده (وضعیت فعلی دفتر کل) و زبان تراکنش (تغییردهندهٔ وضعیت) برای یک دامنه است. هر حوزه (خدمات مالی، مدیریت حقوق دیجیتال DRM، زنجیرهٔ تأمین، سلامت) لایهٔ منطق مخصوص خود را دارد؛ هم محدودکننده و هم قدرتمند، و عملیات بی‌ربط و بالقوه مخرب از اساس وجود ندارند. کاربران انتظار می‌رود خانواده‌های خودشان را بسازند.
• سه خانوادهٔ ارائه‌شده توسط Intel: Endpoint registry (ثبت سرویس‌های دفتر کل)، Integerkey (آزمون دفترهای مستقر) و MarketPlace (خرید، فروش و معامله). پروژهٔ sawtooth_bond نمونهٔ اثبات مفهوم یک پلتفرم معامله اوراق قرضه است.

اجماع در Sawtooth

دو نوع بسته به شبکه: PoET (قرعه‌کشی مبتنی بر TEE) و quorum voting که اقتباسی از پروتکل‌های Ripple و Stellar است و قطعیت فوری تراکنش می‌دهد؛ ویژگی مطلوب در شبکه‌های مجوزدار.

محیط توسعهٔ Sawtooth Lake

کتاب مراحل راه‌اندازی را روی اوبونتو نشان می‌دهد (خلاصه):

• پیش‌نیازها: Vagrant (حداقل ۱٫۹٫۰) و VirtualBox (حداقل 5.0.10).
• کلون مخزن sawtooth-core با git؛ سپس در پوشهٔ tools اجرای vagrant up. توقف ماشین با vagrant halt و توقف و حذف آن با vagrant destroy.
• ورود با vagrant ssh، ساخت هسته با اسکریپت build_all، ساخت بلاک پیدایش و پاک‌سازی دادهٔ قدیمی با genesis.sh.
• اجرای transaction validator با txnvalidator و خانوادهٔ integer_key (و پیکربندی JSON)؛ توقف با Ctrl+C.
• در ترمینالی دیگر کلاینت‌ها (مثلاً کلاینت بازارچه برای خانوادهٔ MarketPlace) به validator وصل می‌شوند؛ کلیدها با دستور sawtooth keygen ساخته می‌شوند.
• کتاب توصیه می‌کند برای نسخه‌های جدید به مستندات رسمی و صفحهٔ نمونه‌های Sawtooth مراجعه شود.

Corda

Corda (از R3، در زمان کتاب رسماً زیر چتر هایپرلجر نبود ولی ممکن بود بپیوندد) بلاک‌چین به معنای دقیق نیست چون تراکنش‌ها را در بلاک‌های زنجیره‌ای دسته‌بندی نمی‌کند و هر بلاک به والد خود هش‌شده پیوند نمی‌خورد؛ ولی یک دفتر کل توزیع‌شده است و مزایای بلاک‌چین را ارائه می‌دهد.

• از صفر برای صنعت مالی طراحی شده تا مشکلات ناشی از ثبت جداگانهٔ دفاتر در هر سازمان (دیدگاه‌های متناقض از «حقیقت»، ریسک عملیاتی، تکرار داده و هزینهٔ زیرساخت) را با یک پلتفرم پایگاه داده غیرمتمرکز حل کند.
• کد به Kotlin (زبان استاتیک‌تایپ روی JVM) نوشته شده است.

معماری

• State objects (اشیای وضعیت): کوچک‌ترین واحد داده که یک توافق مالی را نمایندگی می‌کند؛ در اثر تراکنش ساخته یا مصرف می‌شوند. به کد قرارداد (اجباری، منطق گذار وضعیت) و متن حقوقی (legal prose، اختیاری، برای الزام حقوقی) ارجاع دارند. وضعیت می‌تواند فعال (live) یا تاریخی (historic) باشد. مثال کتاب: توافق ساده‌ای که در آن طرف ABC مبلغ ۱٬۰۰۰ پوند به طرف XYZ پرداخته است. شیء وضعیت را می‌توان یک ماشین حالت دید که تراکنش‌ها آن را مصرف و شیء به‌روزشده تولید می‌کنند.
• تراکنش‌ها: گذار بین وضعیت‌ها؛ مدل UTXO به سبک بیت‌کوین با صفر، یک یا چند ورودی و یک یا چند خروجی؛ همه امضا شده‌اند. ماینینگ ندارد؛ ترتیب زمانی را سرویس‌های notary تأمین می‌کنند. انواع جدید تراکنش با بایت‌کد JVM قابل‌توسعه‌اند.
• اجماع: ساده و مبتنی بر notary. دو مفهوم: اجماع بر اعتبار وضعیت (وجود امضاهای لازم و مناسب‌بودن وضعیت‌ها) و اجماع بر یکتایی وضعیت (تشخیص خرج مضاعف و یکتا‌بودن ورودی‌ها). می‌تواند یک یا چند notary خوشه‌ای باشد و الگوریتم‌هایی مانند PBFT یا Raft را به‌کار گیرد.
• Flows (جریان‌ها): ایدهٔ نو برای ساخت گردش‌کار غیرمتمرکز؛ همهٔ ارتباطات شبکه با flowها انجام می‌شود. پروتکل‌های تراکنش‌ساز که هر جریان مالی با هر پیچیدگی را با کد تعریف می‌کنند، به‌صورت ماشین حالت ناهمگام اجرا می‌شوند، با دیگر گره‌ها و کاربران تعامل دارند و می‌توانند معلق و از سر گرفته شوند.

اجزای شبکه

• Nodes: سازمان‌های مختلف با مدل بدون اعتماد (trust-less) آن‌ها را اجرا می‌کنند و در شبکهٔ P2P احراز‌هویت‌شده‌اند. ارتباط مستقیم با AMQP (استاندارد ISO/IEC 19464) روی TLS؛ ذخیره‌سازی در پایگاه داده رابطه‌ای محلی؛ پیام‌ها در قالب باینری فشرده و با کارگزار پیام Apache Artemis (ActiveMQ). یک گره می‌تواند network map، notary، oracle یا گره معمولی باشد.
• سرویس مجوزدهی (permissioning): صدور گواهی TLS؛ هر شرکت‌کننده باید هویتی امضاشده توسط root CA داشته باشد، یکتا و بر اساس استاندارد X.500 نام‌گذاری شود.
• سرویس نقشهٔ شبکه (network map): سندی از همهٔ گره‌ها (IP، گواهی‌های هویت، فهرست خدمات). گره‌ها در شروع ثبت می‌شوند و هویت‌ها به گره فیزیکی نگاشت می‌شوند.
• سرویس notary: ترتیب و مهر زمانی تراکنش‌ها را می‌دهد؛ چند notary ممکن است با کلیدهای عمومی مرکب شناخته شوند؛ از BFT یا Raft استفاده می‌کنند؛ امضای notary معنای اعتبار و قطعیت دارد. برای کارایی می‌توان بار را بین گره‌ها توزیع کرد و برای کاهش تأخیر گره‌ها را نزدیک شرکت‌کنندگان گذاشت.
• سرویس oracle: یا تراکنش حاوی یک واقعیت را در صورت صحت امضا می‌کند یا خودش داده می‌دهد؛ ورود دنیای واقعی به دفتر کل (فصل ۹).
• تراکنش‌ها در شبکه: هرگز سراسری پخش نمی‌شوند؛ فقط بین زیرمجموعهٔ طرف‌های مرتبط (شبکهٔ نیمه‌خصوصی)، برخلاف بیت‌کوین و اتریوم. اجزای هر تراکنش:
  • ارجاع ورودی (وضعیت‌های مصرفی)، وضعیت‌های خروجی (جدید)؛
  • پیوست‌ها (attachments): هش فایل‌های ZIP (کد/مستندات) که جداگانه منتقل و ذخیره می‌شوند؛
  • دستورها (commands): هدف عملیات به‌عنوان پارامتر قرارداد، با فهرست کلیدهای عمومی طرف‌های امضاکننده؛
  • امضاها: تعدادشان متناسب با کلیدهای دستورهاست؛
  • نوع: عادی یا «تغییر notary»؛
  • مهر زمانی: بازهٔ زمانی که notary اعمال می‌کند؛ برای زمان‌بندی دقیق notary باید با ساعت اتمی همگام باشد؛
  • خلاصه‌ها (summaries): توصیف متنی عملیات.
• Vaults (خزانه‌ها): شبیه کیف پول بیت‌کوین؛ چون تراکنش‌ها سراسری نیستند هر گره فقط دادهٔ مرتبط را نگه می‌دارد. در پایگاه رابطه‌ای ذخیره می‌شوند و با SQL قابل‌پرسوجو هستند؛ می‌توانند داده‌های روی دفتر کل و خارج از آن را داشته باشند.

CorDapp

مدل اصلی (وضعیت‌ها، تراکنش‌ها و پروتکل‌ها) به‌علاوهٔ کد قرارداد، API، افزونه‌های کیف پول و اجزای UI یک برنامهٔ توزیع‌شدهٔ Corda (CorDapp) می‌سازد. قراردادها با Kotlin یا Java برای JVM نوشته می‌شوند؛ JVM اندکی تغییر یافته تا اجرای بایت‌کد قطعی باشد. سه مؤلفهٔ قرارداد: کد اجرایی (منطق اعتبارسنجی تغییرات)، اشیای وضعیت (مصرف یا تولید شونده) و دستورها (داده‌های عملیاتی و تأیید).

محیط توسعهٔ Corda

نیازمندی‌ها: JDK 8 (8u131)، IntelliJ IDEA Community، پایگاه H2، Git، Kotlin و ابزار ساخت Gradle. برای شروع، قالب cordapp-template در دسترس است و مستندات در docs.corda.net. دستور git clone مخزن Corda را می‌گیرد (خروجی نمونه: حدود ۷۴ هزار شیء و ۵۱ مگابایت)، سپس در IntelliJ باز می‌شود. نمونه‌ها در پوشهٔ samples شامل Bank of Corda، interest rate swaps، demo و traders demo هستند.

جمع‌بندی

• هایپرلجر پروژه‌ای چتری و متن‌باز از بنیاد لینوکس برای فناوری‌های بلاک‌چین تجاری و مجوزدار است؛ شامل پنج چارچوب (Fabric، Sawtooth Lake، Iroha، Burrow، Indy) و ابزارهایی (Explorer، Cello، Composer، Quilt).
• Fabric با معماری ماژولار، کانتینر برای chaincode، کانال‌ها، خدمات عضویت (CA/MSP)، و جریان سه‌مرحله‌ای تأیید ← ترتیب‌دهی ← اعتبارسنجی/ثبت، به حریم خصوصی، مقیاس‌پذیری و ممیزی‌پذیری در محیط سازمانی پاسخ می‌دهد.
• Sawtooth Lake با PoET مبتنی بر TEE (با نقد مسئلهٔ stale chips) و خانواده‌های تراکنش (کاهش سطح حمله نسبت به ماشین مجازی همه‌منظوره) رویکرد متفاوتی دارد.
• Corda یک دفتر کل توزیع‌شده بدون بلاک و ماینینگ برای صنعت مالی است: مدل UTXO، notary برای ترتیب و یکتایی، تراکنش‌های نیمه‌خصوصی و flows برای گردش‌کار.
• هر سه پروژه در حال تکامل‌اند ولی مفاهیم هسته‌ای آن‌ها پایدار انتظار می‌رود؛ فصل بعد به بلاک‌چین‌های جایگزین می‌پردازد.

فصل ۱۶ — بلاک‌چین‌های جایگزین (Alternative Blockchains)

مقدمه

پس از موفقیت بیت‌کوین و درک ظرفیت فناوری بلاک‌چین، مجموعه‌ای انبوه از پروتکل‌ها، برنامه‌ها و پلتفرم‌های جدید پدید آمد (کتاب از «انفجار کامبرین» در این حوزه حرف می‌زند). همهٔ این پروژه‌ها موفق نبودند؛ نویسنده به برآوردی اشاره می‌کند که بر اساس آن حدود ۴۶٪ از ICOها در همان سال شکست خورده بودند، اما بخشی از پروژه‌ها جایگاه محکمی پیدا کردند.

این فصل دو دستهٔ اصلی را معرفی می‌کند:

• بلاک‌چین‌های تازه که خودشان شبکه‌ای مستقل‌اند: Kadena، Ripple، Stellar، Rootstock، Quorum، Tezos، Storj، MaidSafe، BigchainDB، MultiChain و Tendermint.
• پلتفرم‌ها و چارچوب‌ها که بر بلاک‌چین‌های موجود سوار می‌شوند و توسعه و استقرار را آسان می‌کنند (در اینجا Eris).

نکتهٔ مشترک این پروژه‌ها آن است که از ایده‌های بیت‌کوین و اتریوم تغذیه کرده‌اند و یا محدودیت‌هایی مثل مقیاس‌پذیری را حل می‌کنند، یا لایه‌ای کاربرپسندتر بالای آن‌ها می‌گذارند. نویسنده تصریح می‌کند که پوشش همهٔ altchainها ممکن نیست و تنها مواردی انتخاب شده‌اند که به فصل‌های قبل مرتبط‌اند یا انتظار می‌رود مورد توجه قرار گیرند.

بلاک‌چین‌ها

Kadena

Kadena یک بلاک‌چین خصوصی (private) است که ادعا می‌کند مسائل مقیاس‌پذیری و حریم خصوصی را حل کرده است. دو نوآوری اصلی دارد: الگوریتم اجماع Scalable BFT و زبان قرارداد هوشمند Pact که عمداً Turing-incomplete است.

تبار Scalable BFT

• مبنای کار الگوریتم Raft است. Tangaroa نسخهٔ مقاوم در برابر خطای بیزانسی (BFT Raft) بود که برای رفع مشکلات دسترس‌پذیری و ایمنی ناشی از گره‌های بیزانسی در Raft ساخته شد، و Juno فورکی از Tangaroa توسط JPMorgan بود.
• هر دو با افزایش تعداد گره‌ها نمی‌توانستند کارایی بالا را حفظ کنند و Juno به همین دلیل چندان فراگیر نشد. Kadena ادعا می‌کند الگوریتم اختصاصی‌اش تا هزاران گره بدون افت کارایی مقیاس می‌پذیرد.

محرمانگی

محرمانگی تراکنش‌ها با ترکیب چند مکانیزم فراهم می‌شود:

• چرخش کلید (key rotation): تعویض دوره‌ای کلیدها برای خنثی‌کردن اثر لو رفتن کلید؛ در زبان Pact پشتیبانی بومی دارد.
• رمزنگاری متقارن روی زنجیره (symmetric on-chain encryption): دادهٔ تراکنش رمز می‌شود و فقط طرف‌های همان تراکنش خصوصی آن را به‌طور خودکار رمزگشایی می‌کنند.
• هش افزایشی (incremental hashing).
• پروتکل Double Ratchet برای مدیریت کلید و رمزنگاری.

جریان تراکنش و اجماع

1. کاربر تراکنش را امضا و در شبکه پخش می‌کند؛ گره رهبر (leader) آن را در لاگ تغییرناپذیر خود می‌نویسد و هش افزایشی لاگ را محاسبه می‌کند. هش افزایشی نوعی هش است که وقتی پیام اولیه اندکی تغییر کند، هش جدید از روی هش قبلی به‌دست می‌آید و سریع‌تر و کم‌هزینه‌تر از هش مجدد کل پیام است.
2. رهبر نسخهٔ همانندسازی و هش افزایشی را امضا و برای سایر گره‌ها پخش می‌کند.
3. گره‌های دیگر امضای رهبر را بررسی، تراکنش را به لاگ خود اضافه و هش افزایشی خودشان (quorum proof) را پخش می‌کنند. وقتی تعداد کافی اثبات رسید، تراکنش برای همیشه در دفتر کل ثبت می‌شود.

اجرای قرارداد

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

زبان Pact

• متن‌باز است و به‌صورت باینری مستقل با REPL عرضه می‌شود (اجرای ./pact در لینوکس). کتاب مثالی در محیط آنلاین Try-Pact نشان می‌دهد: ماژولی با تابع addition که سه ورودی را جمع می‌کند.
• هر قرارداد معمولاً سه بخش دارد: Keysets (طرح‌های مجوزدهی برای جدول‌ها و ماژول‌ها)، Modules (منطق کسب‌وکار به‌شکل تابع و pact؛ pactها چندمرحله‌ای و ترتیبی‌اند) و Tables (ساختار کنترل‌شده با دسترسی؛ مستقیماً فقط ادمین‌های keyset و به‌طور پیش‌فرض کد داخل ماژول به آن‌ها دسترسی دارد).
• سه حالت اجرا: تعریف قرارداد (با یک تراکنش)، اجرای تراکنش و پرس‌وجو (محلی روی گره‌ها برای کارایی).
• سینتکس شبیه LISP است و کد دقیقاً به همان شکل خوانا روی زنجیره ذخیره می‌شود؛ برخلاف EVM که به بایت‌کد کامپایل می‌شود و بررسی کد در حال اجرا را دشوار می‌کند. همچنین Turing-incomplete است، متغیرهای تغییرناپذیر دارد و مقدار null را نمی‌پذیرد، که ایمنی اجرا را بالا می‌برد.

مفهوم Pervasive Determinism و Chainweb

Kadena مفهوم «determinism فراگیر» را مطرح می‌کند: علاوه بر امنیت مبتنی بر کلید عمومی/خصوصی، لایه‌ای از اجماع کاملاً قطعی نیز وجود دارد و امنیت رمزنگاری در همهٔ لایه‌ها (تراکنش و اجماع) تأمین می‌شود. در ژانویهٔ ۲۰۱۸ Kadena یک بلاک‌چین عمومی با معماری زنجیره‌های موازی PoW (Chainweb) معرفی کرد که زنجیره‌های جداگانه‌ای را که روی همتاها استخراج می‌شوند در یک شبکه ترکیب می‌کند و توان پردازش بیش از ۱۰٬۰۰۰ تراکنش در ثانیه را هدف می‌گیرد.

Ripple

Ripple (از ۲۰۱۲) یک سیستم تبادل ارز و تسویهٔ ناخالص بلادرنگ (RTGS) است؛ پرداخت‌ها بدون انتظار تسویه می‌شوند، برخلاف شبکه‌های سنتی که روزها طول می‌کشد. ارز بومی آن XRP است اما پرداخت‌های غیر XRP را هم پشتیبانی می‌کند. کتاب آن را با سیستم قدیمی حواله (Hawala) مقایسه می‌کند: فرستنده پول و یک رمز به نماینده می‌دهد، نمایندهٔ مقصد به کسی که رمز را بگوید پول می‌پردازد؛ معادل نماینده در Ripple «gateway» است (تشبیهی ساده؛ پروتکل واقعی پیچیده‌تر است).

گره‌ها و بحث تمرکززدایی

• User node: برای پرداخت و دریافت.
• Validator node: در اجماع شرکت می‌کند. هر سرور یک UNL (Unique Node List) از گره‌های مورد اعتماد دارد و فقط از رأی‌های آن فهرست استفاده می‌کند.

کتاب می‌گوید گاهی Ripple به‌دلیل وجود اپراتورها و ناظران کاملاً غیرمتمرکز دانسته نمی‌شود؛ اما چون هرکسی می‌تواند validator اجرا کند و تغییر دفتر کل نیازمند رأی اکثریت بالاست، می‌توان آن را غیرمتمرکز دانست. این موضوع همچنان محل مناقشه بین پژوهشگران است.

اجماع RPCA

Ripple یک دفتر کل توزیع‌شدهٔ جهانی دارد که با الگوریتم کم‌تأخیر RPCA (Ripple Protocol Consensus Algorithm) اداره می‌شود. سرورها به‌صورت تکرارشونده تأیید می‌گیرند تا رأی کافی (اکثریت بالا) جمع شود: آستانه از ۵۰٪ شروع و در هر دور تا حداقل ۸۰٪ بالا می‌رود؛ سپس دفتر کل بسته و به کل شبکه اعلام می‌شود. سه فاز:

مؤلفه‌های شبکه

• Server: شرکت‌کننده در اجماع (نیازمند نرم‌افزار سرور Ripple).
• Ledger: ثبت اصلی موجودی حساب‌ها، شامل شمارهٔ دفتر، تنظیمات حساب، تراکنش‌ها، زمان‌مهر و پرچم اعتبار.
• Last closed ledger: دفتری که با اجماع بسته شده.
• Open ledger: دفتر هنوز تأییدنشدهٔ هر گره که تراکنش‌های پیشنهادی را دارد.
• UNL و Proposer (زیرمجموعه‌ای از گره‌ها که تراکنش پیشنهاد می‌دهند).

تراکنش‌ها

هر تراکنش باید امضا و معتبر باشد و مقدار ناچیزی XRP هزینه دارد (محافظت در برابر اسپم و DoS). نوع تراکنش در فیلد TransactionType است و چرخهٔ اجرا چهار مرحله دارد: آماده‌سازی (تراکنش امضانشده طبق استاندارد)، امضا، ارسال از طریق سرور متصل و در پایان تأیید. دسته‌بندی:

فیلدهای مشترک همهٔ تراکنش‌ها: Account، AccountTxnID (هش تراکنش دیگر برای زنجیر کردن)، Fee، Flags، LastLedgerSequence، Memos، SigningPubKey، Signers، SourceTag و TxnSignature. آدرس حساب به‌صورت base58 از کلید عمومی اصلی مشتق می‌شود.

Interledger

Interledger پروتکلی چهارلایه برای پرداخت میان دفترهای کل متفاوت است:

Ripple Connect مجموعه‌ای plug-and-play بر پایهٔ ILP است که تبادل داده پیش از تراکنش، مدیریت کارمزد، تأیید تحویل و ارتباط امن با TLS را فراهم می‌کند. هدف Ripple صنعت مالی و پرداخت بلادرنگ بدون ریسک تسویه است.

Stellar

Stellar شبکهٔ پرداخت مبتنی بر بلاک‌چین با مدل اجماع FBA (Federated Byzantine Agreement) است که حول quorum‌هایی از طرف‌های مورد اعتماد کار می‌کند؛ پیاده‌سازی آن SCP (Stellar Consensus Protocol) نام دارد. انگیزهٔ آن، هزینه و پیچیدگی زیرساخت مالی فعلی است. چهار ویژگی SCP:

• کنترل غیرمتمرکز: مشارکت برای همه بدون مرجع مرکزی؛
• تأخیر کم؛
• اعتماد انعطاف‌پذیر: کاربر انتخاب می‌کند به چه کسانی برای چه منظوری اعتماد کند؛
• امنیت مجانبی (asymptotic): تکیه بر امضای دیجیتال و هش.

ارز بومی Lumens (XLM) است که با پخش تراکنش مصرف می‌شود و سد دفاعی در برابر DoS است. دفتر کل توزیع‌شده روی هر سرور تکثیر می‌شود و می‌تواند به‌عنوان دفتر سفارش (order book) توزیع‌شده نیز عمل کند: کاربران پیشنهاد خرید/فروش ارز ثبت می‌کنند. هستهٔ نرم‌افزار در stellar-core روی GitHub در دسترس است.

Rootstock (RSK)

برای فهم Rootstock سه مفهوم لازم است:

• اتصال دوطرفه (two-way pegging): انتقال ارزش بین دو زنجیره. در واقع سکه‌ای جابه‌جا نمی‌شود؛ همان مقدار روی زنجیرهٔ اصلی بیت‌کوین قفل و معادلش روی زنجیرهٔ ثانویه آزاد می‌شود.
• Sidechain (ایدهٔ اولیهٔ Blockstream): بلاک‌چینی موازی با زنجیرهٔ اصلی که انتقال ارزش بین دو زنجیره را ممکن می‌کند؛ اعتبار بازگشت سکه معمولاً از طریق مکانیزم SPV تأیید می‌شود.
• Drivechain: مفهومی جدیدتر که در آن کنترل آزادسازی بیت‌کوین‌های قفل‌شده به ماینرها داده می‌شود و آن‌ها رأی می‌دهند چه زمانی باز شود.

RSK پلتفرم قرارداد هوشمند با peg دوطرفه به بلاک‌چین بیت‌کوین است؛ هدف آن افزایش مقیاس‌پذیری و کارایی بیت‌کوین و فراهم‌کردن قابلیت قرارداد هوشمند است. ماشین مجازی آن (RVM) Turing-complete و قطعی است، با EVM سازگار است و قراردادهای کامپایل‌شدهٔ Solidity را اجرا می‌کند. با merge mining با بیت‌کوین، به سطح امنیت مشابه (به‌ویژه در برابر double spend و قطعیت تسویه) می‌رسد و به‌خاطر زمان بلاک کوتاه‌تر تا حدود ۴۰۰ تراکنش در ثانیه را هدف دارد. شبکهٔ اصلی بتا با نام Bamboo (RSK MainNet) منتشر شده بود.

Quorum

Quorum (ساخت JPMorgan) نسخهٔ ارتقایافتهٔ اتریوم برای کاربردهای سازمانی است با حریم خصوصی تراکنش، اجماع جدید، مجوزدهی گره‌ها با قرارداد هوشمند و کارایی بالاتر از اتریوم عمومی. مؤلفه‌ها:

• Transaction manager: دسترسی به دادهٔ رمزشدهٔ تراکنش، مدیریت ذخیره‌سازی محلی و ارتباط با سایر transaction managerها.
• Crypto Enclave: سرویس‌های رمزنگاری و مدیریت کلید.
• QuorumChain: اجماع BFT مبتنی بر رأی اکثریت و زمان؛ قرارداد هوشمند فرایند اجماع را مدیریت می‌کند. نقش‌های گره: Voter (رأی‌دهنده) و Maker (سازندهٔ بلوک)؛ هر گره می‌تواند هیچ‌کدام، یکی یا (به‌طراحی) نقش مشخصی داشته باشد.
• Network manager: لایهٔ کنترل دسترسی برای شبکهٔ مجوزدار.

حریم خصوصی با رمزنگاری و این اصل تأمین می‌شود که برخی تراکنش‌ها فقط برای طرف‌های مربوط قابل مشاهده‌اند (شبیه تراکنش‌های خصوصی Corda در فصل ۱۵). چون تراکنش عمومی و خصوصی هر دو وجود دارند، پایگاه وضعیت دو بخش می‌شود: دو درخت Patricia-Merkle جدا برای وضعیت عمومی و خصوصی؛ و هش وضعیت قرارداد خصوصی به‌عنوان شاهد اجماع میان طرفین استفاده می‌شود. تراکنش Quorum شامل گیرنده، امضای فرستنده، مقدار اختیاری اتر، فهرست اختیاری شرکت‌کنندگان مجاز به دیدن تراکنش و فیلد هش (برای تراکنش خصوصی) است.

مسیر یک تراکنش خصوصی:

1. DApp تراکنش را از طریق API به گره Quorum می‌دهد.
2. API محموله را رمز می‌کند و هش آن را حساب و به transaction manager می‌فرستد.
3. transaction manager امضا را بررسی و پیام را ذخیره می‌کند.
4. هش محمولهٔ رمزشده به گره Quorum برمی‌گردد.
5. هنگام اعتبارسنجی بلوکی که شامل تراکنش خصوصی است، گره داده‌های بیشتر را از transaction manager می‌خواهد.
6. transaction manager محمولهٔ رمزشده و کلیدهای متقارن را می‌فرستد.
7. گره رمزگشایی می‌کند و برای اجرا به EVM می‌دهد.

به این ترتیب، رمزنگاری متقارن روی زنجیره با پروتکل بومی اتریوم و EVM ترکیب می‌شود. ایدهٔ مشابه اما متفاوتی قبلاً با HydraChain (دفاتر مجوزدار بر پایهٔ اتریوم) مطرح شده بود.

Tezos

Tezos دفتر کل رمزنگاری‌شدهٔ خودتغییردهنده (self-amending) است: نه‌تنها بر وضعیت زنجیره، بلکه بر نحوهٔ تکامل پروتکل و گره‌ها هم اجماع غیرمتمرکز دارد. هدف آن رفع مشکلاتی مثل هارد فورک‌ها، هزینه و تمرکز قدرت ماینینگ در PoW، اسکریپت‌نویسی محدود و مسائل امنیتی بیت‌کوین است. به زبان تابعی OCaml نوشته شده است.

• معماری سه‌لایه: شبکه، اجماع و تراکنش. یک shell عمومی شبکه، مسئول نگهداری زنجیره (ترکیب لایهٔ اجماع و تراکنش) و واسط میان شبکه و پروتکل است؛ همین جداسازی تکامل غیرمتمرکز پروتکل را ممکن می‌کند.
• Seed protocol: شروع زنجیره به‌جای بلاک پیدایش از یک پروتکل بذر است که روال اصلاح بلاک‌چین و حتی خود فرایند اصلاح را تعریف می‌کند و سهام‌داران تغییرات را تأیید می‌کنند.
• پاداش‌ها بر پایهٔ PoS است و ماینینگ لازم نیست.
• زبان قرارداد: پشته‌محور و Turing-complete، با قابلیت تأیید صوری (formal verification) برای اثبات ریاضی درستی کد.
• کراودفاندینگ ICO به مبلغ ۲۳۲ میلیون دلار؛ شبکهٔ عمومی برای سه‌ماههٔ اول ۲۰۱۸ برنامه‌ریزی شده بود.

Storj

Storj ذخیره‌سازی ابری توزیع‌شده و غیرمتمرکز مبتنی بر بلاک‌چین است که به‌جای سازمان مرکزی، جامعه آن را اداره می‌کند. گره‌ها به‌عنوان عامل‌های خودمختار قرارداد ذخیره‌سازی اجرا می‌کنند و انتقال، اعتبارسنجی و بررسی صحت داده را انجام می‌دهند.

• هسته: جدول هش توزیع‌شده Kademlia با پیام‌ها و قابلیت‌های افزوده؛ و سازوکار pub/sub همتابههمتا به نام Quasar که با فیلتر بلوم (topics) پارامترهای قرارداد ذخیره‌سازی را برای گره‌های علاقه‌مند منتشر می‌کند.
• فایل‌ها ابتدا با AES-256-CTR رمز و سپس تکه‌تکه (sharding) در شبکه پخش می‌شوند؛ این کار دسترس‌پذیری، امنیت، کارایی و حریم خصوصی را بالا می‌برد. هر shard به‌طور پیش‌فرض در سه مکان نگهداری می‌شود.
• هر کس می‌تواند فضای دیسک اضافی‌اش را به اشتراک بگذارد و با ارز Storjcoin X (SJCX) (در اصل دارایی Counterparty روی بیت‌کوین، بعدها مهاجرت به اتریوم) پاداش بگیرد.

MaidSafe

شبکهٔ SAFE سامانهٔ ذخیره‌سازی توزیع‌شده‌ای شبیه Storj است. مشارکت‌کنندگان با Safecoin برای فضای ذخیره‌شان پرداخت می‌گیرند و میزان پرداخت با proof of resource کنترل می‌شود (اگر فضای تعهدشده در دسترس نباشد، پرداخت کاهش می‌یابد). مفاهیم خاص:

• فایل‌ها رمز و به قطعات کوچک تقسیم می‌شوند؛
• opportunistic caching: ساخت کپی داده‌های پرمراجعه نزدیک‌تر به متقاضیان برای کارایی بیشتر؛
• حذف خودکار دادهٔ تکراری برای کاهش نیاز ذخیره‌سازی؛
• churning: جابه‌جایی مداوم داده در شبکه تا هدف مهاجمان نشود، و نگهداری چند نسخه برای افزونگی.

BigchainDB

BigchainDB در اصل یک پایگاه دادهٔ توزیع‌شده است که ویژگی‌های بلاک‌چین (تمرکززدایی، تغییرناپذیری، مدیریت دارایی دیجیتال) را دارد و پرس‌وجوی NoSQL را پشتیبانی می‌کند. هدف آن این است که در کنار پردازش غیرمتمرکز (بلاک‌چین) و فایل‌سیستم غیرمتمرکز (مثل IPFS)، پایگاه داده هم غیرمتمرکز باشد تا کل اکوسیستم برنامه غیرمتمرکز شود.

MultiChain

MultiChain پلتفرمی برای ساخت و استقرار بلاک‌چین‌های خصوصی بر پایهٔ کد بیت‌کوین است؛ به مسائل امنیت، مقیاس‌پذیری و حریم خصوصی می‌پردازد، پارامترهای زنجیره در آن بسیار قابل تنظیم است، لایهٔ مجوزدهی ریزدانه دارد و نصب آن سریع است.

Tendermint

Tendermint نرم‌افزاری است که اجماع BFT و تکثیر ماشین حالت (state machine replication) را برای هر برنامه فراهم می‌کند. دو بخش دارد:

• Tendermint Core: موتور اجماع که تکرار امن تراکنش‌ها را در همهٔ گره‌ها تضمین می‌کند.
• TMSP (Tendermint Socket Protocol): واسط برنامه که اجازه می‌دهد تراکنش‌ها با هر زبان برنامه‌نویسی پردازش شوند؛ در نتیجه فرایند برنامه از فرایند اجماع جدا می‌شود.

الگوریتم مبتنی بر دور است: در هر دور validatorها بلوک پیشنهاد می‌دهند و مکانیزم قفل (locking) مانع commit دو بلوک مختلف در یک ارتفاع می‌شود. هر validator یک دفتر کل کامل محلی دارد؛ سرایند بلوک شامل هش بلوک قبلی، زمان‌مهر پیشنهاد، ارتفاع و ریشهٔ Merkle تراکنش‌هاست.

Cosmos از Tendermint استفاده می‌کند و شبکه‌ای از بلاک‌چین‌های BFT است که zone نام دارند. نخستین zone یعنی Cosmos Hub بلاک‌چین عمومی با ارز Atom است که با پروتکل IBC (Inter Blockchain Communication) زنجیره‌ها را متصل می‌کند. IBC دو نوع تراکنش دارد: IBCBlockCommitTx (اثبات آخرین هش بلوک یک زنجیره) و IBCPacketTx (احراز مبدأ داده). برای ارسال بستهٔ داده ابتدا اثبات آن روی زنجیرهٔ مقصد منتشر می‌شود و زنجیرهٔ مقصد با بررسی آن مطمئن می‌شود که فرستنده واقعاً بسته را منتشر کرده است. این طرح مقیاس‌پذیری و interoperability را هدف می‌گیرد.

پلتفرم‌ها و چارچوب‌ها

Eris

Eris (از Monax) یک زنجیره نیست؛ پلتفرم ماژولار و متن‌باز برای توسعهٔ «برنامه‌های اکوسیستمی» با پشتوانهٔ بلاک‌چین است و چارچوب، SDK و ابزار فراهم می‌کند. از قراردادهای Solidity استفاده می‌کند و می‌تواند با اتریوم یا بیت‌کوین کار کند (اتصال، شروع، توقف، قطع ارتباط و ساخت بلاک‌چین‌های جدید). پیچیدگی راه‌اندازی انتزاع شده و دستورها برای همهٔ بلاک‌چین‌ها یکسان است. یک API gateway به برنامه‌های قدیمی اجازهٔ اتصال به مدیریت کلید، موتور اجماع و موتور برنامه را می‌دهد.

ابزارهای (toolkit) آن:

علاوه بر آن SDKهای تخصصی با قراردادهای آزمایش‌شده وجود دارد (مالی، بیمه، لجستیک) به‌همراه یک SDK پایه برای مدیریت چرخهٔ عمر برنامه.

eris:db کلاینت بلاک‌چین مجوزدار Monax و مبتنی بر PoS است و چهار بخش دارد: اجماع (Tendermint)، ماشین مجازی (EVM)، لایهٔ مجوزها (اختصاص نقش به موجودیت‌ها) و واسط (ابزار خط فرمان و RPC). تفاوت‌های کلیدی با اتریوم:

(در متن کتاب نام منحنی با غلط املایی ed22519 آمده است.)

جمع‌بندی

• حوزهٔ بلاک‌چین بسیار سریع تغییر می‌کند و این فصل گزیده‌ای از زنجیره‌ها و پلتفرم‌هاست: Kadena (Scalable BFT و Pact)، Ripple (RPCA و Interledger)، Stellar (FBA/SCP)، Rootstock (sidechain/merge mining)، Quorum (اتریوم سازمانی با حریم خصوصی)، Tezos (حاکمیت و خودتغییری پروتکل)، Storj و MaidSafe (ذخیره‌سازی غیرمتمرکز)، BigchainDB (پایگاه داده)، MultiChain (بلاک‌چین خصوصی)، Tendermint/Cosmos (اجماع BFT و interoperability) و Eris (چارچوب توسعه).
• محورهای تکرارشونده: اجماع BFT برای شبکه‌های مجوزدار، حریم خصوصی از راه رمزنگاری، همکاری‌پذیری بین زنجیره‌ها (peg، Interledger، IBC) و تفکیک موتور اجماع از منطق برنامه.
• نویسنده پروژه‌های دیگری مانند Tau-Chain، HydraChain، Elements و CREDITS را نیز نام می‌برد که پوشش داده نشده‌اند و خوانندگان را به پیگیری تحولات این حوزه تشویق می‌کند. فصل بعد به کاربردهای بلاک‌چین خارج از ارزهای دیجیتال، به‌ویژه اینترنت اشیا، می‌پردازد.

فصل ۱۷ — بلاک‌چین فراتر از ارزهای دیجیتال (Blockchain – Outside of Currencies)

مقدمه

ارزهای دیجیتال نخستین کاربرد بلاک‌چین بودند و تا حدی بی‌آنکه ظرفیت واقعی فناوری درک شود. بیت‌کوین مفهوم بلاک‌چین را معرفی کرد، اما تازه حدود سال ۲۰۱۳ بود که کاربردهای آن در صنایع دیگر جدی گرفته شد: مالی، اینترنت اشیا (IoT)، مدیریت حقوق دیجیتال، دولت و حقوق و غیره. این فصل با کمک موردکاوی، چهار حوزهٔ اصلی را بررسی می‌کند: اینترنت اشیا، دولت، سلامت و مالی (در بخش مالی بیمه، تسویهٔ پس از معامله، پیشگیری از جرم مالی و در پایان رسانه نیز می‌آید).

یک یادداشت تاریخی: در ۲۰۱۰ بحث دربارهٔ BitDNS (سامانهٔ نام‌گذاری غیرمتمرکز دامنه‌ها) آغاز شد و Namecoin در آوریل ۲۰۱۱ با چشم‌اندازی متفاوت از بیت‌کوین (که فقط پول الکترونیکی است) شروع به کار کرد. این را می‌توان اولین نمونهٔ استفادهٔ غیرارزی از بلاک‌چین دانست. از ۲۰۱۳ به بعد ایده‌های متعددی پدید آمد و این روند به‌شدت رشد کرد.

اینترنت اشیا (Internet of Things)

تعریف و کارکردها

IoT شبکه‌ای از اشیای فیزیکی هوشمند (خودرو، یخچال، حسگر صنعتی و …) است که به اینترنت وصل می‌شوند، رویدادهای محیط واقعی را حس می‌کنند، واکنش نشان می‌دهند، داده جمع می‌کنند و از طریق اینترنت ارتباط برقرار می‌کنند. مفاهیمی چون پوشیدنی‌ها (wearables)، خانهٔ هوشمند، شبکهٔ برق هوشمند، خودروی متصل و شهر هوشمند بر همین پایه‌اند. چهار کارکرد یک دستگاه IoT:

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

مدل پنج‌لایهٔ IoT

1. لایهٔ اشیای فیزیکی: هر چیزی که باید پایش یا کنترل شود، از انسان و حیوان تا کارخانه، قطار و خانه.
2. لایهٔ دستگاه: حسگرها (دما، رطوبت، جریان مایع، مواد شیمیایی، هوا، فشار و …)، مبدل‌ها، محرک‌ها، گوشی‌ها و دستگاه‌های هوشمند و برچسب‌های RFID. برای تبدیل سیگنال آنالوگ جهان واقعی به دیجیتال به ADC نیاز است و برای فرمان‌دادن به قطعات مکانیکی (مثل روشن‌کردن موتور یا باز کردن در) به مبدل دیجیتال به آنالوگ.
3. لایهٔ شبکه: gateway، روتر، هاب و سوییچ برای اتصال به اینترنت و ابر. دو نوع ارتباط: افقی (بلوتوث، Wi-Fi، Zigbee، اترنت، PAN و رادیو بین دستگاه‌ها) و ارتباط با لایهٔ بالاتر (معمولاً از راه اینترنت).
4. لایهٔ مدیریت: پلتفرم‌های پردازش داده و استخراج بینش، مدیریت دستگاه، امنیت و جریان داده، و ارتباط میان لایهٔ دستگاه و برنامه.
5. لایهٔ برنامه: کاربردهایی مانند حمل‌ونقل، سلامت، مالی، بیمه و مدیریت زنجیرهٔ تأمین.

ارزانی حسگر، سخت‌افزار و پهنای باند، IPv6، پردازنده‌های کوچک‌تر و قوی‌تر و بهبود دسترسی اینترنت در رواج IoT نقش داشته‌اند. مزایا از صرفه‌جویی هزینه تا تصمیم‌گیری بهتر کسب‌وکار بر اساس داده را شامل می‌شود؛ مثلاً کنتورهای هوشمند انرژی اطلاعات مصرف را به شرکت خدمات‌دهنده منتقل می‌کنند.

مشکل مدل متمرکز و راه‌حل بلاک‌چین

مدل متداول IoT متمرکز است: دستگاه‌ها به ابر یا سرور مرکزی گزارش می‌دهند. این تمرکز احتمال هک و سرقت داده را بالا می‌برد و کنترل داده‌های شخصی را به یک ارائه‌دهنده می‌سپارد. بلاک‌چین بنا به نظر IBM اعتماد می‌سازد، هزینه را کم و تراکنش‌ها را سریع می‌کند. نکات مهم:

• حذف نقطهٔ شکست واحد (single point of failure): سرور مرکزی احتمالاً از پس داده‌های میلیاردها دستگاه برنمی‌آید. برآورد کتاب: حدود ۲۲ میلیارد دستگاه متصل تا ۲۰۲۰.
• مدل همتابههمتا نیاز به مراکز داده گران و PKI پیچیده را کم می‌کند و دستگاه‌ها مستقیم یا از طریق روتر گفتگو می‌کنند.
• با قراردادهای هوشمند، مذاکره و پرداخت مستقیماً بین دستگاه‌ها و بدون واسطه یا دخالت انسان رخ می‌دهد. مثال‌ها: اتاق خالی هتل که خودش را اجاره می‌دهد، کرایه را مذاکره می‌کند و قفل را برای کسی که مبلغ درست را پرداخته باز می‌کند؛ ماشین لباسشویی که وقتی پودر تمام شد، بهترین قیمت را پیدا و سفارش می‌دهد.
• مقاومت در برابر حملات DoS، چون هدف متمرکزی وجود ندارد.
• امکان دریافت به‌روزرسانی فریم‌ور و امنیتی دستگاه‌ها از یکدیگر؛ و ثبت تغییرناپذیر و ایمن این ارتباطات برای ممیزی‌پذیری، یکپارچگی و شفافیت (چیزی که شبکه‌های P2P سنتی ندارند).
• ذخیره‌سازی و پردازش می‌تواند بین دستگاه‌ها توزیع شود و نیاز به مراکز داده بزرگ را حذف کند.

مدل IoT مبتنی بر بلاک‌چین: یک لایهٔ بلاک‌چین روی لایهٔ شبکه اضافه می‌شود که قرارداد هوشمند اجرا می‌کند و امنیت، حریم خصوصی، یکپارچگی، خودمختاری، مقیاس‌پذیری و تمرکززدایی را فراهم می‌کند. لایهٔ مدیریت تنها نرم‌افزار تحلیل و پردازش را نگه می‌دارد و امنیت و کنترل به بلاک‌چین منتقل می‌شود. بلاک‌چین مانند میان‌افزار میان همهٔ شرکت‌کنندگان است. پروژه‌هایی مانند IBM Blue Horizon و IBM Bluemix (پشتیبان IoT مبتنی بر بلاک‌چین) و استارت‌آپ‌هایی مانند Filament در این زمینه فعال‌اند.

آزمایش عملی: IoT و بلاک‌چین اتریوم با Raspberry Pi

هدف: ساخت دستگاه IoT ساده که به بلاک‌چین اتریوم وصل است و در پاسخ به فراخوانی یک قرارداد هوشمند، یک LED را روشن می‌کند (LED نمادی از قفل در). نسخهٔ تولیدی نیازمند آزمون دقیق‌تر است، اما اصل کار را نشان می‌دهد.

سخت‌افزار: Raspberry Pi 3 Model B (کامپیوتر تک‌برد SBC و کم‌هزینه که برای آموزش ساخته شد و برای IoT محبوب است).

مراحل راه‌اندازی نرم‌افزار:

1. نصب سیستم‌عامل Raspbian از طریق NOOBS روی کارت SD؛ با uname -a معماری (armv7l) مشخص می‌شود تا باینری ARM مناسب Geth دانلود شود.
2. دانلود با wget و استخراج با tar نسخهٔ Geth برای ARM (نسخهٔ ۱٫۵٫۶ در کتاب) و کپی باینری در مسیر سیستم.
3. استفاده از همان فایل genesis که در فصل ۱۲ برای شبکهٔ خصوصی ساخته شد (chainId برابر ۷۸۶، difficulty برابر 0x0400 و بدون alloc)، وگرنه گره‌ها عملاً در شبکه‌های جدا کار می‌کنند.
4. اجرای geth init genesis.json برای ساخت بلاک پیدایش.
5. افزودن همتا با فایل static-nodes.json حاوی شناسهٔ enode همتا که از دستور admin.nodeInfo در کنسول Geth همتا به‌دست می‌آید.

راه‌اندازی دو گره: گره اول با --networkid 786، --maxpeers 5، RPC فعال روی پورت ۹۰۰۱، --rpccorsdomain "*"، پورت P2P برابر ۳۰۳۰۱ و --identity برای نام‌گذاری گره. گره Raspberry Pi با همان networkid و پورت‌های متفاوت (P2P روی ۳۰۳۰۲). استفاده از پورت‌های مختلف الزامی نیست ولی برای port forwarding و DMZ توصیه می‌شود. پیام «Block synchronisation started» نشان‌دهندهٔ اتصال موفق است. با geth attach و دستور admin.peers در هر دو گره اتصال همتایان بررسی می‌شود.

پیش‌نیازها: نصب Node.js (نسخهٔ ۷ از طریق NodeSource و apt-get؛ کتاب npm 4.0.5 و node v7.4.0 را استفاده کرده)، کتابخانهٔ web3 نسخهٔ پایدار ۰٫۲۰٫۲ (نه نسخهٔ بتای ۱٫۰ که به‌طور پیش‌فرض نصب می‌شود) و بستهٔ onoff برای کنترل پایه‌های GPIO.

مدار: LED، مقاومت ۳۳۰ اهم، breadboard (ساخت مدار بدون لحیم)، T-cobbler (نمایش برچسب‌دار پایه‌های GPIO) و کابل ribbon برای اتصال Raspberry Pi به breadboard. پایهٔ مثبت (بلند) LED به پین GPIO شمارهٔ ۲۱ و پایهٔ منفی (کوتاه) از طریق مقاومت به GND وصل می‌شود.

قرارداد هوشمند: قراردادی ساده در Solidity با تابع getRent(uint8 x) که مقدار مورد انتظار (در مثال: ۱۰) را می‌گیرد. اگر مقدار درست باشد، رویداد (event) roomRented را صادر می‌کند؛ در غیر این صورت رویدادی صادر نمی‌شود. نسخهٔ پیچیده‌تر می‌تواند مبلغ اتر ارسالی را بررسی کند. قرارداد در Remix IDE آزمایش می‌شود و ABI آن (شامل تابع getRent و رویداد roomRented) از بخش Details به‌دست می‌آید.

دو الگوی اتصال Raspberry Pi به شبکه: (۱) اجرای کلاینت Geth محلی با دفتر کل محلی؛ (۲) در دستگاه‌های کم‌منبع که اجرای گره کامل یا حتی light ممکن نیست، اتصال از راه web3 provider به یک کانال RPC دیگر. در حالت دوم، افشای RPC خطر امنیتی دارد؛ فقط برای شبکهٔ خصوصی یا با محدودیت IP، غیرفعال‌کردن کشف همتا و اقدامات سنتی مثل فایروال و TLS توصیه می‌شود.

استقرار و اجرا: قرارداد با truffle migrate روی شبکهٔ ۷۸۶ مستقر می‌شود. سپس برنامهٔ Node.js (index.js) این کارها را انجام می‌دهد: اتصال به web3 با HttpProvider روی پورت RPC محلی (در مثال ۹۰۰۲، پیش‌فرض ۸۵۴۵)، ساخت شیء Gpio روی پین ۲۱ به‌عنوان خروجی، ساختن شیء قرارداد با ABI و آدرس قرارداد (آدرس مختص هر استقرار است و باید تغییر کند)، و ثبت شنونده برای رویداد roomRented که هنگام وقوع، پیام «LED On» چاپ و led.writeSync(1) را اجرا می‌کند. اجرا با node index.js. سپس از کنسول Truffle تابع getRent(10) فراخوانی می‌شود؛ پس از mine شدن تراکنش، رویداد صادر و LED روشن می‌شود.

نتیجه: می‌توان شبکهٔ خصوصی از دستگاه‌های IoT ساخت که هرکدام Geth اجرا می‌کنند، به رویدادهای قرارداد هوشمند گوش می‌دهند و کنترل فیزیکی را از طریق قرارداد انجام می‌دهند.

دولت (Government)

دولت الکترونیک یعنی استفاده از فناوری اطلاعات و ارتباطات برای ارائهٔ خدمات عمومی. بسیاری از دولت‌ها بلاک‌چین را برای کارت شناسایی، گواهینامه، اشتراک امن داده بین ادارات و مدیریت قرارداد بررسی می‌کنند؛ ویژگی‌های شفافیت، ممیزی‌پذیری و یکپارچگی بلاک‌چین مفیدند.

کنترل مرزی (Border control)

کنترل مرزی خودکار سال‌هاست برای جلوگیری از ورود غیرقانونی، تروریسم و قاچاق انسان استفاده می‌شود. استاندارد MRTD (سند سفر ماشین‌خوان) در سند ICAO 9303 (سازمان بین‌المللی هواپیمایی کشوری) تعریف شده و گذرنامه‌های بیومتریک دارای ویژگی‌هایی مانند اسکن شبکیه، اثر انگشت، تشخیص چهره و MRZ (ناحیهٔ ماشین‌خوان) هستند.

مشکلات فعلی: سامانه‌ها در اختیار یک نهاد است و داده به‌راحتی بین سازمان‌های مجری قانون به اشتراک گذاشته نمی‌شود؛ همچنین مکانیزمی برای باطل‌کردن فوری یک گذرنامهٔ مشکوک و پخش آن به مرزهای جهان وجود ندارد.

راه‌حل بلاک‌چینی: فهرست سیاه (blacklist) در یک قرارداد هوشمند نگه داشته می‌شود و هر تغییر فوراً برای همهٔ سازمان‌ها و گیت‌ها قابل مشاهده است. در برابر PKI و شبکه‌های P2P سنتی، سیستم ساده‌تر و ارزان‌تر می‌شود و تغییرناپذیری رمزنگاری‌شده ممیزی را ساده و تقلب را دشوار می‌کند. چون ذخیرهٔ کل پایگاه داده روی بلاک‌چین (به‌خاطر مقیاس‌پذیری) مناسب نیست، پایگاه داده پشتیبان مثل BigchainDB، IPFS یا Swarm استفاده می‌شود و فقط هش سند سفر همراه شناسهٔ بیومتریک در قرارداد ذخیره می‌شود. قرارداد می‌تواند آرایه‌ای از هویت‌ها (هش MRZ الحاق‌شده به رکورد بیومتریک تراشهٔ RFID) و یک پرچم بولی برای فهرست سیاه داشته باشد. پس از این بررسی اولیه، راستی‌آزمایی بیومتریک دقیق‌تر با سیستم‌های سنتی انجام می‌شود و تصمیم نهایی دوباره روی بلاک‌چین ثبت و بین همه به اشتراک گذاشته می‌شود.

جریان سناریو: گذرنامه با اسکنر RFID و صفحه خوانده می‌شود؛ داده ماشین‌خوان و هش بیومتریک تراشه استخراج می‌شود و عکس زنده و اسکن شبکیه گرفته می‌شود. قرارداد هوشمند ابتدا فهرست سیاه را می‌سنجد و سپس داده‌های بیشتر را از IPFS می‌گیرد. دادهٔ بیومتریک خام روی بلاک‌چین نیست؛ فقط مرجع آن. اگر همه چیز مطابقت داشت، گیت باز می‌شود. این رویکرد به مبارزه با تروریسم و امنیت داخلی کمک می‌کند و می‌تواند بین کنسرسیومی جهانی از ادارات امنیت ملی مشترک باشد.

رأی‌گیری (Voting)

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

• یکپارچگی و اصالت رأی با رمزنگاری کلید عمومی؛
• تغییرناپذیری که مانع ثبت دوباره می‌شود؛ ترکیب بیومتریک (مثل اثر انگشت) با قرارداد هوشمندی که فهرست رأی‌های ثبت‌شده را نگه می‌دارد، از رأی مضاعف جلوگیری می‌کند؛
• اثبات دانش صفر (Zero-Knowledge Proofs) برای حفظ حریم خصوصی رأی‌دهنده.

نمونه‌ها: سرویس Polys و انتخابات ریاست‌جمهوری سیرالئون که به گزارش کتاب نخستین انتخابات با استفاده از بلاک‌چین بود.

شناسایی شهروندان (کارت ملی)

کارت‌های شناسایی الکترونیک امروز ایمن‌اند، اما بلاک‌چین می‌تواند بهبودهایی بیاورد. هویت دیجیتال محدود به کارت دولتی نیست و در شبکه‌های اجتماعی و فروم‌ها هم هست. هویت مبتنی بر بلاک‌چین اجازه می‌دهد کاربر ببیند چه کسی و برای چه هدفی از داده‌اش استفاده کرده و دسترسی را کنترل کند، که در زیرساخت‌های متمرکز ممکن نیست. یک هویت دولتی می‌تواند برای چند سرویس (بازنشستگی، مالیات، مزایا) روی یک بلاک‌چین دولتی به‌کار رود و هر تغییر در رکورد دائمی بماند. شهروندان می‌توانند شناسنامه، ازدواج‌نامه، سند ملکی و … را با هویت دیجیتال خود روی بلاک‌چین ثبت و اثبات وجود کنند.

نقد: نظام‌های هویتی موجود در بسیاری از کشورها خوب کار می‌کنند و ممکن است بلاک‌چین ضروری نباشد؛ فناوری هنوز برای هویت واقعی بالغ نیست. افزون بر این، قوانینی مثل «حق فراموش‌شدن» با ماهیت تغییرناپذیر بلاک‌چین در تعارض‌اند. با این حال تحقیقات دولت‌ها ادامه دارد.

موارد متفرقه

وصول مالیات، مدیریت و پرداخت مزایا، ثبت مالکیت زمین، ثبت وقایع حیاتی (تولد، ازدواج)، ثبت خودرو و صدور مجوزها از دیگر نمونه‌های کاربرد بالقوه‌اند؛ مزایای اصلی: تغییرناپذیری، شفافیت و تمرکززدایی.

سلامت (Health)

حوزهٔ سلامت از سامانه‌ای تغییرناپذیر، قابل ممیزی و شفاف سود می‌برد که شبکه‌های P2P سنتی ندارند و زیرساختی ساده‌تر و ارزان‌تر از PKIهای پیچیده فراهم می‌کند. مشکلات رایج: نقض حریم خصوصی، نشت داده، هزینهٔ بالا و تقلب که از نبود همکاری‌پذیری، فرایندهای پیچیده، کمبود شفافیت و ممیزی و کنترل ناشی می‌شود. داروهای تقلبی نیز به‌ویژه در کشورهای در حال توسعه نگرانی جدی است. مزایای مورد انتظار: صرفه‌جویی هزینه، افزایش اعتماد، پردازش سریع‌تر ادعاها (claims)، دسترس‌پذیری بالا، کاهش خطای عملیاتی و جلوگیری از توزیع داروی تقلبی.

کاربرد دیگر، بلاک‌چین‌هایی که به ماینر توکن می‌دهند تا توان پردازشی را صرف مسائل علمی کنند: FoldingCoin (توکن FLDC برای به‌اشتراک‌گذاری توان محاسباتی در محاسبات سنگین علمی) و CureCoin. هنوز مشخص نیست این طرح‌ها چقدر موفق خواهند بود اما ایده امیدوارکننده است.

مالی (Finance)

صنعت مالی داغ‌ترین موضوع بلاک‌چین است و بانک‌های بزرگ عمدتاً به‌خاطر پتانسیل کاهش هزینه آن را بررسی می‌کنند.

بیمه

بلاک‌چین می‌تواند ادعاهای تقلبی را متوقف، پردازش را سریع و شفافیت را ایجاد کند. تصور کنید دفتر کل مشترک میان همهٔ بیمه‌گران برای مدیریت ادعاهای بین‌شرکتی. ادعاها می‌توانند با قرارداد هوشمند و هویت بیمه‌گذار خودکار تأیید و پرداخت شوند. با همگرایی IoT و بلاک‌چین، اشیای هوشمند می‌توانند سیاست‌های بیمه را مدیریت کنند. مثال بیمهٔ خودرو: قرارداد هوشمند با کمک اوراکل و IoT اطلاعات تله‌متری هنگام تصادف را ثبت و بر اساس شرایط، پرداخت را آزاد یا متوقف می‌کند (مثلاً اگر تعمیر در کارگاه مجاز نبوده یا خودرو خارج از محدودهٔ تعیین‌شده استفاده شده است). قوانین دلخواه بیمه‌گر است، اما می‌توان کل بیمهٔ خودرو را خودکار کرد. استارت‌آپ Dynamis بیمهٔ همتابههمتا روی اتریوم (ابتدا برای بیمهٔ بیکاری) و بدون نیاز به underwriter پیشنهاد کرده است.

تسویهٔ پس از معامله (Post-trade settlement)

پرکاربردترین و موردانتظارترین کاربرد مالی. چرخهٔ معامله سه مرحله دارد:

در مدل سنتی یک clearinghouse مرکزی ریسک اعتباری هر دو طرف را می‌پذیرد و مسیر معامله از شرکت‌ها، کارگزاران، چیرینگ‌هاوس‌ها و custodianها می‌گذرد. تسویه معمولاً دو تا سه روز طول می‌کشد و به سیستم‌های reconciliation وابسته است. با یک دفتر کل مشترک و قرارداد هوشمند، همه یک «نسخهٔ واحد حقیقت» از وضعیت معامله می‌بینند، تسویهٔ P2P ممکن است و پیچیدگی، هزینه، ریسک و زمان کم می‌شود، واسطه‌ها حذف می‌شوند و ناظران می‌توانند برای ممیزی ببینند. این کار به رعایت مقررات MiFID II هم کمک می‌کند.

پیشگیری از جرم مالی

KYC (Know Your Customer) و AML (ضد پولشویی) ارکان مبارزه با جرم مالی‌اند. در KYC امروزی هر مؤسسه نسخهٔ خودش از داده‌های مشتری را نگه می‌دارد و از ارائه‌دهندگان متمرکز راستی‌آزمایی می‌گیرد؛ این کند است و ورود مشتری جدید را به تأخیر می‌اندازد. دفتر کل مشترک بین مؤسسات مالی با هویت‌های تأییدشده، که فقط با اجماع شرکت‌کنندگان به‌روز می‌شود، هزینه را کم و رعایت مقررات را یکنواخت‌تر می‌کند. در AML، ناظران می‌توانند به بلاک‌چین خصوصی دسترسی بگیرند و داده‌های گزارش‌دهی را مستقیماً بردارند، به‌جای تجمیع داده از سیستم‌های قدیمی و پراکنده؛ نمای مشترک تراکنش‌های رمزنگاری‌شده، اصیل و قابل ممیزی.

رسانه (Media)

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

جمع‌بندی

• بلاک‌چین در صنایع مختلف کاربرد دارد؛ فصل پنج حوزه را پوشش داد: IoT، دولت، سلامت، مالی (با بیمه، تسویه، KYC/AML) و رسانه.
• IoT مهم‌ترین و آمادهٔ‌ترین نامزد برای ترکیب با بلاک‌چین است؛ بلاک‌چین ضعف‌های مقیاس‌پذیری، حریم خصوصی، اعتماد و نقطهٔ شکست واحد مدل متمرکز را برطرف می‌کند. آزمایش Raspberry Pi نشان داد یک رویداد قرارداد هوشمند (roomRented) چگونه با Geth، web3 و GPIO یک عملگر فیزیکی را کنترل می‌کند. پلتفرم‌هایی مانند IBM Watson IoT و IBM Blue Horizon وجود دارند.
• در دولت: کنترل مرزی با فهرست سیاه مشترک، رأی‌گیری شفاف (همراه با ZKP) و هویت دیجیتال، با این هشدار که بلوغ فناوری و تعارض با «حق فراموش‌شدن» مانع می‌شوند.
• بخش مالی با شور و هیجان بلاک‌چین را بررسی می‌کند اما تا سیستم‌های آمادهٔ تولید فاصله دارد.
• همهٔ این کاربردها بر ستون‌های ویژگی‌های اصلی بلاک‌چین، یعنی تمرکززدایی، شفافیت، قابلیت اطمینان و امنیت، استوارند؛ اما چالش‌هایی (مقیاس‌پذیری، حریم خصوصی و …) باید حل شود که موضوع فصل بعد است.

فصل ۱۸ — مقیاس‌پذیری و چالش‌های دیگر (Scalability and Other Challenges)

مقدمه

این فصل چالش‌هایی را مرور می‌کند که پیش از رسیدن بلاک‌چین به یک فناوری فراگیر باید حل شوند. با آنکه کاربردها و نمونه‌های اثبات مفهوم (proof of concept) فراوانی ساخته شده و فناوری در بسیاری سناریوها خوب کار می‌کند، هنوز محدودیت‌های بنیادینی وجود دارد که پذیرش گسترده را کند می‌کند. دو مورد در صدر فهرست‌اند:

• مقیاس‌پذیری (Scalability): بلاک‌چین‌ها به سطح کارایی که کاربران انتظار دارند نمی‌رسند.
• حریم خصوصی (Privacy): صنایعی مانند مالی، حقوقی و سلامت به محرمانگی تراکنش‌ها نیاز دارند، در حالی که دفتر کل عمومی ذاتاً شفاف است.

افزون بر این دو، فصل به امنیت می‌پردازد: حتی در بیت‌کوین، که امنیتش آزمون زمان را پس داده، گوشه‌های ظریفی وجود دارد، و در اتریوم نگرانی‌هایی دربارهٔ قراردادهای هوشمند، حملات منع سرویس (DoS) و سطح حملهٔ بزرگ مطرح است. (مباحثی مانند مقررات‌گذاری و یکپارچه‌سازی در مقدمه فقط نام برده می‌شوند.)

مقیاس‌پذیری

نویسنده آن را مهم‌ترین مسئله می‌داند: تفاوت میان پذیرش گستردهٔ بلاک‌چین و محدود ماندنش به استفادهٔ خصوصی در کنسرسیوم‌ها. راه‌حل‌ها را می‌توان در دو دسته جای داد:

• راه‌حل‌های درون‌زنجیره‌ای (on-chain): تغییر پروتکل‌های بنیادین بلاک‌چین (مثلاً بزرگ‌کردن بلاک).
• راه‌حل‌های برون‌زنجیره‌ای (off-chain): استفاده از منابع شبکه و پردازش بیرون از زنجیره برای تقویت آن (مثلاً شبکه‌های حالت).

مدل «صفحه‌ها» (Planes) از Miller و همکاران

در مقاله‌ای با عنوان On Scaling Decentralized Blockchains بلاک‌چین به لایه‌های انتزاعی‌ای به نام صفحه (plane) تقسیم شده تا گلوگاه‌ها در هر لایه جداگانه و ساختارمند بررسی شوند:

راهکارهای عمومی مقیاس‌پذیری

افزایش اندازهٔ بلاک (Block size increase). پرمناقشه‌ترین پیشنهاد. بیت‌کوین حدود ۳ تا ۷ تراکنش در ثانیه پردازش می‌کند و این برای ریزپرداخت‌ها (microtransactions) کافی نیست. اندازهٔ بلاک در بیت‌کوین به‌صورت ثابت ۱ مگابایت است؛ بزرگ‌تر شدن آن تراکنش بیشتر و تأیید سریع‌تر می‌دهد. چند BIP در این جهت داده شد: BIP 100، 101، 102، 103 و 109. در اتریوم اندازهٔ بلاک سخت‌کد نیست و با gas limit کنترل می‌شود؛ ماینرها می‌توانند آن را برای بلاک‌های بعد بالا ببرند، پس در تئوری سقفی ندارد. SegWit در بیت‌کوین با جداکردن داده‌های witness از دادهٔ تراکنش فضای بیشتری برای تراکنش‌ها ساخت. گزینه‌های دیگر: Bitcoin Unlimited، Bitcoin XT و Bitcoin Cash.

کاهش فاصلهٔ بلاک‌ها (Block interval reduction). زمان کمتر بین بلاک‌ها قطعیت سریع‌تر می‌دهد، اما به‌دلیل فورک‌های بیشتر امنیت را کم می‌کند. اتریوم به حدود ۱۴ ثانیه رسیده (در برابر ۱۰ دقیقهٔ بیت‌کوین) و مشکل بلاک‌های یتیم (orphan) را با پروتکل GHOST (Greedy Heaviest Observed Subtree) کم می‌کند که در آن بلاک‌های «عمو» (uncle) هم در تعیین زنجیرهٔ معتبر لحاظ می‌شوند. با گذار به PoS دیگر استخراج لازم نیست و قطعیت تقریباً فوری ممکن می‌شود.

جداول جست‌وجوی بلوم وارون‌پذیر (IBLT). پیشنهاد Gavin Andresen برای کم‌کردن داده‌ای که بین گره‌ها منتقل می‌شود: به‌جای ارسال همهٔ تراکنش‌ها، فقط آن‌هایی فرستاده می‌شوند که در حوضچهٔ تراکنش (mempool) گرهٔ همگام‌شونده نیست. مزیت مهم: پیاده‌سازی‌اش هاردفورک لازم ندارد.

شاردینگ (Sharding). تکنیکی قدیمی در پایگاه‌های داده (MongoDB، MySQL): کار به قطعه‌هایی تقسیم و بین گره‌های مختلف پردازش می‌شود تا توان عملیاتی بالا و نیاز ذخیره‌سازی کم شود. در بلاک‌چین، وضعیت شبکه (موجودی‌ها، کد، nonce، storage) بین چند شارد تقسیم می‌شود؛ شاردها پارتیشن‌هایی با اتصال سست روی همان شبکه‌اند. چالش‌های باز: ارتباط بین شاردها و اجماع روی تاریخچهٔ هر شارد.

کانال‌های حالت (State channels). بخشی از وضعیت بلاک‌چین خارج از زنجیره به‌روز می‌شود و فقط نتیجهٔ نهایی روی زنجیره نوشته می‌شود. سه گام:

1. بخشی از وضعیت زیر یک قرارداد هوشمند قفل می‌شود تا توافق و منطق کسب‌وکار میان طرفین تضمین شود.
2. طرفین بیرون از زنجیره هر تعداد تراکنش را فقط بین خودشان انجام می‌دهند؛ همین باعث سرعت بالاست. (نویسنده اذعان می‌کند این یک راه‌حل «واقعاً درون‌زنجیره‌ای» مثل شاردینگ نیست، ولی شبکه‌ای سریع‌تر و سبک‌تر می‌دهد؛ مناسب ریزپرداخت و اینترنت اشیا.)
3. با رسیدن به وضعیت نهایی، کانال بسته می‌شود، حالت نهایی روی بلاک‌چین ثبت می‌شود و بخش قفل‌شده آزاد می‌شود.

نمونه‌ها: Lightning Network در بیت‌کوین و Raiden در اتریوم.

بلاک‌چین خصوصی (Private blockchain). چون تمرکززدایی واقعی نیست و شرکت‌کنندگان استخراج نمی‌کنند و فقط تراکنش را اعتبارسنجی می‌کنند، ذاتاً سریع است. اما این یک دور زدن مسئله است نه حل آن و فقط در محیط‌هایی مانند سازمان‌ها (که همهٔ اعضا شناخته‌شده‌اند) کاربرد دارد.

اثبات سهام (PoS). بلاک‌چین‌های مبتنی بر PoS ذاتاً سریع‌ترند (توضیح بیشتر در فصل ۸ کتاب).

زنجیره‌های جانبی (Sidechains). مقیاس‌پذیری را غیرمستقیم بهبود می‌دهند: زنجیره‌های سریع‌تر (و احتمالاً کم‌امنیت‌تر) در کنار زنجیرهٔ اصلی اجرا می‌شوند و با آن پیوند دارند. مفهوم هسته: اتصال دوطرفه (two-way peg) برای انتقال سکه از زنجیرهٔ والد به زنجیرهٔ جانبی و برعکس.

زیرزنجیره‌ها (Subchains). پیشنهاد Peter R. Rizun بر پایهٔ «بلاک‌های ضعیف» (weak blocks): بلاک‌هایی که به سختی استاندارد شبکه نرسیده‌اند اما یک هدف سختی ضعیف‌تر را برآورده کرده‌اند. ماینرها این بلاک‌های ضعیف را روی هم لایه‌بندی می‌کنند تا بلاکی که سختی استاندارد را برآورده می‌کند پیدا شود؛ آنگاه زیرزنجیره بسته شده و «بلاک قوی» می‌شود. مزایا: انتظار کمتر برای نخستین تأیید، احتمال کمتر بلاک یتیم، پردازش سریع‌تر. نیازی به سافت‌فورک یا هاردفورک ندارد ولی پذیرش جامعه لازم است.

زنجیره‌های درختی (Tree chains). تغییر ساختار بلاک‌چین از خطی به یک درخت دودویی که از زنجیرهٔ اصلی بیت‌کوین منشعب می‌شود. شبیه sidechain است و تغییر عمدهٔ پروتکل یا بزرگ‌کردن بلاک نمی‌خواهد؛ زنجیره‌ها قطعه‌قطعه و توزیع‌شده می‌شوند. برای اعتبارسنجی بلاک‌ها در این درخت استخراج لازم نیست و کاربران خودشان هدر بلاک را راستی‌آزمایی می‌کنند. هنوز آمادهٔ تولید نیست.

بهبودهای ویژهٔ بیت‌کوین (Christian Decker)

Decker در کتاب On the Scalability and Security of Bitcoin با هدف کم‌کردن زمان انتشار (که علت فورک‌هاست) سه بهبود پیشنهاد می‌کند که بدون تغییر پروتکل و فقط در نرم‌افزار گره قابل پیاده‌سازی‌اند:

• حداقل‌سازی اعتبارسنجی: گره می‌تواند به‌محض عبور از بررسی اولیهٔ PoW و اعتبار بلاک، پیام inventory را بفرستد و منتظر اتمام اعتبارسنجی همهٔ تراکنش‌ها نماند.
• خط‌لولهٔ (pipelining) انتشار بلاک: حضور بلاک پیش از در دسترس بودن واقعی آن اعلام می‌شود تا زمان رفت‌وبرگشت بین گره‌ها کم شود.
• افزایش اتصال‌پذیری: اتصال هر گره به گره‌های بیشتر فاصلهٔ شبکه را کم و انتشار را سریع‌تر می‌کند.

راه‌حل نهایی احتمالاً ترکیبی از چند رویکرد خواهد بود. SegWit نمونهٔ آمادهٔ اجراست: فقط به سافت‌فورک نیاز دارد، امضا را از تراکنش جدا می‌کند، مشکل تغییرپذیری تراکنش (malleability) را برطرف می‌کند و افزایش ظرفیت بلاک را ممکن می‌سازد.

Bitcoin-NG

بلاک‌ها دو نوع می‌شوند:

• بلاک رهبر (leader/key block): مسئول PoW است.
• ریزبلاک (microblock): حاوی تراکنش‌های واقعی؛ نیازی به PoW ندارد و رهبر برگزیده در طول چرخهٔ تولید بلاک (که با بلاک رهبر آغاز می‌شود) آن‌ها را با کلید خصوصی خود امضا می‌کند. چون رهبر می‌تواند بسیار سریع ریزبلاک بسازد، کارایی و سرعت تراکنش بالا می‌رود.

«کاغذ ارغوانی» (Mauve Paper) و Plasma

• Mauve paper نوشتهٔ Vitalik Buterin (ارائه‌شده در Devcon2 شانگهای) چشم‌انداز اتریوم مقیاس‌پذیر را با ترکیب شاردینگ و PoS توصیف می‌کند. اهداف: کارایی بیشتر با PoS، سریع‌ترین زمان بلاک ممکن، قطعیت اقتصادی (economic finality)، مقیاس‌پذیری، ارتباط بین شاردها و مقاومت در برابر سانسور.
• Plasma از Joseph Poon و Vitalik Buterin: قراردادهای هوشمند روی زنجیرهٔ ریشه (Ethereum MainNet) اجرا می‌شوند و زنجیره‌های فرزند تعداد زیادی تراکنش را پردازش کرده و فقط تعهدهای (commitments) کوچک را به والد برمی‌گردانند. زنجیره‌ها به‌صورت درخت سلسله‌مراتبی‌اند و استخراج فقط روی ریشه انجام می‌شود که اثبات‌های امنیتی را به پایین می‌رساند. این یک سامانهٔ لایهٔ ۲ (Layer 2) است، مانند کانال‌های حالت که روی زنجیرهٔ اصلی نیستند.

حریم خصوصی

در بلاک‌چین‌های عمومی همه‌چیز شفاف است و همین استفاده در مالی و سلامت را دشوار می‌کند. چهار خانوادهٔ فناوری اصلی (به‌علاوهٔ چند روش دیگر) مطرح‌اند:

مبهم‌سازی غیرقابل‌تمایز (Indistinguishability Obfuscation, IO). احتمالاً «گلوله نقره‌ای» حریم خصوصی، اما هنوز برای تولید آماده نیست. کد برنامه را با عناصر تصادفی چنان درهم می‌آمیزد که اگر درست اجرا شود خروجی مورد انتظار می‌دهد و هر روش اجرای دیگری فقط خروجی بی‌معنی تولید می‌کند (ایدهٔ «پازل جیگساو چندخطی»). اگر روی بلاک‌چین اعمال شود، قرارداد هوشمند به جعبه‌سیاه تبدیل می‌شود.

رمزنگاری همومورفیک (Homomorphic encryption). امکان انجام عملیات روی داده‌های رمزشده؛ مثلاً سرور ابری داده را پردازش و نتیجه را بدون دانستن محتوا برمی‌گرداند. نوع کاملاً همومورفیک (FHE) هنوز آمادهٔ تولید نیست ولی پیشرفت‌های مهمی شده است. روی بلاک‌چین می‌تواند محاسبه روی متن رمزشده را ممکن کند. پروژهٔ Enigma از MIT Media Lab شبکه‌ای نظیربه‌نظیر است که چند طرف روی داده‌های رمزشده محاسبه می‌کنند بی‌آنکه چیزی فاش شود.

اثبات‌های دانش صفر (ZKPs). در Zcash با zk-SNARK (Succinct Non-Interactive Argument of Knowledge) با موفقیت به‌کار رفته است. تلفیق Zcash با اتریوم پروژهٔ تحقیقاتی فعال تیم R&D اتریوم و شرکت Zcash است. ZK-STARK (Zero-Knowledge Succinct Transparent Argument of Knowledge) نسخهٔ بهبودیافته است: پهنای باند و فضای کمتر، بدون نیاز به «تنظیم مورد اعتماد» (trusted setup) مناقشه‌برانگیز SNARK، و سریع‌تر چون به‌جای منحنی‌های بیضوی بر هش‌ها تکیه دارد.

کانال‌های حالت. چون همهٔ تراکنش‌ها بیرون از زنجیره‌اند و زنجیرهٔ اصلی فقط خروجی نهایی را می‌بیند، حریم خصوصی هم حاصل می‌شود.

محاسبهٔ چندجانبهٔ امن (Secure multiparty computation). داده با اشتراک رازی (secret sharing) بین طرف‌ها تقسیم می‌شود و پردازش بدون بازسازی داده روی یک ماشین انجام می‌شود؛ خروجی هم بین طرف‌ها تقسیم می‌ماند.

سخت‌افزار برای محرمانگی. پلتفرم‌های محاسبات مورد اعتماد مانند Intel SGX کد را در محیط محافظت‌شدهٔ سخت‌افزاری به نام enclave اجرا می‌کنند و پس از اجرای موفق، اثباتی به نام quote تولید می‌شود که سرورهای ابری Intel آن را تأیید می‌کنند. اگر روی قراردادهای هوشمند اعمال شود، یک گره پس از اجرا quote می‌سازد و بقیه فقط آن را راستی‌آزمایی می‌کنند. انتقاد: اعتماد به Intel نوعی تمرکز است و با روح بلاک‌چین نمی‌خواند، هرچند بسیاری از پلتفرم‌ها اصلاً روی تراشهٔ Intel هستند. ایده را می‌توان به هر محیط اجرای مورد اعتماد (TEE) تعمیم داد، حتی روی گوشی با NFC و secure element.

CoinJoin. بی‌نام‌سازی تراکنش‌های بیت‌کوین با ترکیب تعاملی: چند نفر یک تراکنش واحد می‌سازند بدون اینکه ورودی‌ها و خروجی‌ها تغییر کنند؛ پیوند مستقیم فرستنده/گیرنده شکسته می‌شود. به همکاری چند طرف نیاز دارد، و اگر یکی از شرکت‌کنندگان امضا نکند، می‌تواند حملهٔ منع سرویس رخ دهد. برخلاف سرویس‌های میکسر (mixing service) به شخص ثالث مورد اعتماد نیاز ندارد.

تراکنش‌های محرمانه (Confidential transactions). بر پایهٔ تعهد پدرسن (Pedersen commitment). طرح تعهد اجازه می‌دهد کاربر به مقداری متعهد شود و آن را پنهان نگه دارد و بعداً فاش کند. دو ویژگی لازم: binding (پس از تعهد نتوان مقدار را عوض کرد) و hiding (مهاجم نتواند مقدار اصلی را بیابد). تعهدهای پدرسن جمع‌پذیرند و خاصیت جابه‌جایی را حفظ می‌کنند (به‌نوعی همومورفیک)، پس مبلغ تراکنش را می‌شود پنهان کرد. در پروژهٔ Elements پیاده‌سازی شده است.

MimbleWimble. طرحی که به‌صورت مرموز در کانال IRC بیت‌کوین مطرح شد؛ تراکنش‌های محرمانه و CoinJoin را بدون نیاز به تعامل تجمیع می‌کند. چون زبان اسکریپت بیت‌کوین و برخی ویژگی‌های دیگر را پشتیبانی نمی‌کند با پروتکل بیت‌کوین ناسازگار است؛ پس یا به‌صورت sidechain یا رمزارزی مستقل پیاده می‌شود. هم حریم خصوصی و هم مقیاس‌پذیری را هدف می‌گیرد. بلاک‌هایش به‌جای تراکنش‌های سنتی از سه فهرست تشکیل می‌شود: ورودی‌ها (ارجاع به خروجی‌های قدیمی)، خروجی‌ها (خروجی‌های محرمانه) و excessها (امضاها و اختلاف خروجی‌ها و ورودی‌ها). خروجی‌ها فقط کلید عمومی دارند و اختلاف قدیم و جدید را همهٔ طرف‌ها امضا می‌کنند.

امنیت

با اینکه بلاک‌چین از رمزنگاری نامتقارن و متقارن استفاده می‌کند، ملاحظاتی هست:

• تغییرپذیری تراکنش (Transaction malleability): مهاجم شناسهٔ یکتای تراکنش را پیش از تأیید تغییر می‌دهد و ممکن است برداشت یا واریز دوباره یا ظاهراً «انجام‌نشده» به نظر برسد. راه‌حل‌ها: BIP 62 و SegWit. این مشکل فقط برای فرایندهایی است که به تراکنش‌های تأییدنشده تکیه می‌کنند؛ برنامه‌هایی که فقط تراکنش تأییدشده را معتبر می‌دانند مشکلی ندارند.
• حملهٔ eclipse: گرهٔ بیت‌کوین فریب می‌خورد و فقط به IPهای مهاجم وصل می‌شود، که راه را برای دوبار خرج‌کردن و حمله ۵۱٪ باز می‌کند. در نسخهٔ ۰٫۱۰٫۱ کلاینت تا حدی رفع شد.
• امکان دوبار خرج‌کردن (double spending) در سناریوهای خاص.

امنیت قراردادهای هوشمند

حادثهٔ بدنام DAO باعث شد تحقیقات دربارهٔ امنیت قراردادها و به‌ویژه راستی‌آزمایی صوری (formal verification) رونق بگیرد. راستی‌آزمایی صوری یعنی بررسی اینکه برنامه گزاره‌های صوری مشخصی را برآورده می‌کند؛ برنامهٔ مبدأ به مجموعه‌ای از گزاره‌ها تبدیل می‌شود که اثبات‌گرهای خودکار بفهمند. ابزارهای مثال: Frama-C برای C؛ Why3 که راستی‌آزمای Solidity هم از آن استفاده می‌کند. ابزار Oyente (از مقالهٔ Making Smart Contracts Smarter) قراردادهای Solidity را تحلیل می‌کند.

دسته‌بندی آسیب‌پذیری‌ها:

ابزارها و مثال‌ها

• Remix IDE: تب Analysis کد را از نظر امنیت، gas و اقتصاد تحلیل می‌کند و در مثال، باگ reentrancy را با موفقیت شناسایی کرد.
• Why3: مثالی نشان داده شد که در آن متغیر uint با حداکثر مقدارش مقداردهی می‌شود و با سرریز به ۰ برمی‌گردد؛ Why3 این خطا را گزارش می‌کند. نکته: تبدیل Solidity به Why3 در کامپایلر آنلاین دیگر موجود نیست و مثال برای نشان‌دادن یک دستهٔ باگ است که با ابزارهای سنتی دیده نمی‌شود. هشدار: راستی‌آزمایی صوری معجزه نیست، چون مشخصات (specification) هم باید درست تعریف شود.
• Oyente: به‌صورت Docker image عرضه می‌شود. روی قراردادی از مستندات Solidity (با تابع withdraw که مقدار share را تا آخر تابع صفر نمی‌کند، لذا فراخوانی بازگشتی دوباره برداشت می‌کند) آزمایش و باگ reentrancy یافت شد. راه‌حل پیشنهادی: الگوی Checks-Effects-Interactions. نسخهٔ آنلاین هم در دسترس است.
• ابزار آنلاین دیگر: securify.ch.

جمع‌بندی

این فصل نشان داد که مقیاس‌پذیری و حریم خصوصی دو مانع اصلی پذیرش گستردهٔ بلاک‌چین‌اند. برای مقیاس‌پذیری، رویکردهای متنوعی از تغییر پارامترهای پروتکل (بلاک بزرگ‌تر، فاصلهٔ کمتر، SegWit) تا شاردینگ، کانال‌های حالت، Plasma، sidechain، Bitcoin-NG و PoS مطرح است، و پاسخ نهایی احتمالاً ترکیبی از آن‌هاست. برای حریم خصوصی، ابزارهایی مانند ZKP، رمزنگاری همومورفیک، MPC، TEE، CoinJoin، تراکنش‌های محرمانه و MimbleWimble هرکدام مزایا و محدودیت‌های خود را دارند و برخی هنوز در مرحلهٔ پژوهش‌اند. در امنیت، به‌ویژه امنیت قراردادهای هوشمند، دسته‌بندی باگ‌ها (reentrancy، سرریز عدد، وابستگی به ترتیب و زمان) و ابزارهای تحلیل و راستی‌آزمایی صوری معرفی شد؛ این ابزارها هنوز در حال توسعه و کم‌مستندند و جایگزین طراحی دقیق و مشخصات درست نمی‌شوند. نویسنده انتظار دارد با پیشرفت پژوهش، ابزارهای خودکار بیشتری برای راستی‌آزمایی قراردادها پدید آید.

فصل ۱۹ — چشم‌انداز کنونی و گام بعدی (Current Landscape and What’s Next)

مقدمه

نویسنده می‌گوید فناوری بلاک‌چین شیوهٔ انجام کسب‌وکار روزمره را تغییر می‌دهد و مدل‌های کسب‌وکار موجود را به چالش کشیده است؛ وعده‌اش صرفه‌جویی هزینه، کارایی بیشتر و شفافیت است. این فصل پایانی، آخرین تحولات، روندهای نوظهور، مسائل باز و پیش‌بینی‌های آینده را مرور می‌کند. ساختار فصل: روندهای نوظهور، چالش‌های دیگر (مقررات، «سمت تاریک»)، موضوعات پژوهشی، پروژه‌های برجسته، ابزارهای متفرقه، همگرایی با فناوری‌های دیگر و پیش‌بینی آینده.

روندهای نوظهور (Emerging trends)

با بلوغ فناوری و علاقهٔ شدید دانشگاه و صنعت، روندهایی شکل گرفته‌اند.

بلاک‌چین‌های ویژهٔ یک کاربرد (ASBC)

تمایلی به ساخت بلاک‌چین یا دفتر کل توزیع‌شده‌ای برای فقط یک کاربرد و یک صنعت خاص دیده می‌شود. نمونه: Everledger که تاریخچهٔ تغییرناپذیر و مسیر حسابرسی برای الماس و کالاهای گران‌قیمت فراهم می‌کند؛ مالکیت، اصالت و ارزش ثبت و راستی‌آزمایی می‌شود، لذا تقلب سخت می‌شود و برای بیمه و نهادهای مجری قانون ارزشمند است.

بلاک‌چین‌های درجهٔ سازمانی (Enterprise-grade)

بلاک‌چین‌های اولیه به‌دلیل مشکلات حریم خصوصی و مقیاس‌پذیری برای سازمان‌ها آماده نبودند؛ پس شرکت‌هایی راه‌حل‌هایی عرضه می‌کنند که آزمون، مستندسازی، یکپارچه‌سازی و امنیتشان از قبل پوشش داده شده و با کمترین تغییر در سازمان قابل استقرارند. این با بلاک‌چین‌های عمومی (بدون مقررات و بدون برآوردن الزامات امنیتی سازمانی) متفاوت است. معمولاً در پیکربندی خصوصی پیاده می‌شوند، اما نسخهٔ عمومی هم ممکن است. استارتاپ‌های نمونه: Bloq، Tymlez، Chain، Colu، ChainThat و ChromaWay.

بلاک‌چین‌های خصوصی

به‌دلیل نیاز به حریم خصوصی و محرمانگی، تمرکز زیادی بر دفاتر کل خصوصی میان گروه شرکت‌کنندگان مورد اعتماد است. بلاک‌چین‌های عمومی چون محرمانگی ندارند برای مالی، پزشکی و حقوق مناسب نیستند؛ در بلاک‌چین خصوصی شرکت‌کنندگان کنترل کامل سیستم را دارند. اتریوم هم در حالت عمومی و هم خصوصی کاربرد دارد، در حالی که Hyperledger و Corda صرفاً خصوصی طراحی شده‌اند (فصل ۱۵).

سایر روندها

• استارتاپ‌ها: رشد چشمگیر استارتاپ‌های مشاوره و راه‌حل بلاک‌چین؛ فهرست angel.co در زمان کتاب حدود ۱٬۹۲۷ استارتاپ را نشان می‌داد.
• علاقهٔ پژوهشی قوی: هم در دانشگاه (رمزنگاری، سازوکار اجماع، کارایی) و هم صنعت. چون بلاک‌چین زیرمجموعهٔ سیستم‌های توزیع‌شده است، پژوهشگران این حوزه به آن روی آورده‌اند. نمونه‌ها: مرکز تحقیقات فناوری‌های بلاک‌چین UCL، گروه محاسبات توزیع‌شدهٔ ETH Zurich، نشریهٔ Ledger Journal و سازمان IC3 (Initiative for Cryptocurrencies & Contracts) که روی کارایی، محرمانگی و ایمنی بلاک‌چین‌ها و قراردادهای هوشمند کار می‌کند.
• استانداردسازی: فناوری هنوز به‌سادگی با سیستم‌های موجود یکپارچه نمی‌شود و حتی دو شبکهٔ بلاک‌چین نمی‌توانند به‌راحتی با هم صحبت کنند. مهم‌ترین گام: کمیتهٔ فنی ISO/TC 307 برای استانداردسازی بلاک‌چین و فناوری دفتر کل توزیع‌شده، با هدف افزایش interoperability و تبادل داده. کنسرسیوم R3 (بیش از ۸۰ بانک) و Hyperledger (معماری مرجع، با پشتیبانی Linux Foundation) نیز عملاً با اشتراک ایده و کد به استانداردسازی کمک می‌کنند. مثال دیگر: استاندارد Open Chain / Chain OS1 برای شبکه‌های مالی که با همکاری نهادهای مالی بزرگ ساخته شد، تسویهٔ سریع‌تر و مسیریابی مستقیم همتابه‌همتا را هدف می‌گیرد، الزامات مقرراتی/امنیتی/حریم خصوصی را در نظر دارد، چارچوب توسعهٔ قرارداد هوشمند می‌دهد و رعایت AML و KYC را آسان می‌کند. برای قراردادهای هوشمند هم مقالهٔ Lee و همکاران قالب‌های قرارداد را رسماً تعریف کرده است.
• بهبودها (Enhancements): پیشنهادهای بهبود مانند BIP برای بیت‌کوین و EIP برای اتریوم مرتب ارائه می‌شود؛ پاسخ به آسیب‌پذیری‌ها و محدودیت‌هایی مانند مقیاس‌پذیری، حریم خصوصی و interoperability.
• پیاده‌سازی‌های دنیای واقعی: در ۲۰۱۷ نمونه‌های اثبات مفهوم فراوان ساخته شد (مثلاً Everledger برای الماس و Filament برای IoT). گام بعد استقرار واقعی است: مثلاً هفت بانک برای ساخت Digital Trade Chain (DTC) جهت ساده‌کردن تأمین مالی تجارت توافق کردند، و بورس اوراق بهادار استرالیا (ASX) در حال جایگزینی سیستم پس از معامله (post-trade) قدیمی خود با بلاک‌چین است.
• کنسرسیوم‌ها: رشد کنسرسیوم‌ها و تلاش‌های متن‌باز؛ نمونهٔ شاخص R3 که Corda را با بزرگ‌ترین مؤسسات مالی جهان توسعه داد.
• پاسخ به چالش‌های فنی: کانال‌های حالت (Lightning و Raiden که تقریباً آمادهٔ استقرارند)، راه‌حل‌هایی مانند Kadena برای محرمانگی، و Zcash، CoinJoin و تراکنش‌های محرمانه (فصل ۸).
• همگرایی: ترکیب بلاک‌چین (تاب‌آوری، امنیت، شفافیت) با فناوری‌های دیگر؛ IoT از یکپارچگی، تمرکززدایی و مقیاس‌پذیری سود می‌برد و هوش مصنوعی از طریق عامل‌های خودمختار (Autonomous Agents, AA).
• آموزش: منابع آموزشی رسمی کم است، ولی دوره‌هایی مانند دورهٔ آنلاین Princeton دربارهٔ بیت‌کوین و فناوری‌های رمزارز ارائه می‌شود و مؤسسات خصوصی هم آموزش می‌دهند.
• اشتغال: استخدام متخصصان و توسعه‌دهندگان بلاک‌چین (به‌ویژه در مالی) در حال رشد است و کمبود توسعه‌دهنده با آموزش و خودآموزی جبران خواهد شد.
• رمزاقتصاد (Cryptoeconomics): مطالعهٔ پروتکل‌های حاکم بر اقتصاد دیجیتال غیرمتمرکز؛ Vitalik Buterin آن را ترکیبی از ریاضیات، رمزنگاری، اقتصاد و نظریهٔ بازی‌ها تعریف کرده است.
• پژوهش رمزنگاری: احیای علاقه، به‌ویژه رمزنگاری مالی. ZKP، رمزنگاری کاملاً همومورفیک و رمزنگاری تابعی (functional encryption) برای بلاک‌چین بررسی می‌شوند و Zcash نخستین کاربرد عملی ZKP است.
• زبان‌های برنامه‌نویسی جدید: تمرکز بر زبان‌های حوزه‌محور، مثل Solidity برای اتریوم و Pact برای Kadena.
• پژوهش سخت‌افزاری: از ۲۰۱۰ ماینرها از CPU به GPU، سپس FPGA و در نهایت ASIC رفتند؛ پژوهش‌ها بر موازی‌سازی و کوچک‌کردن die ادامه دارد. ارزهای جدید با PoW مناسب GPU (مثل Zcash) علاقه به رگ‌های GPU و برنامه‌نویسی با CUDA و OpenCL را بالا برده‌اند. همچنین Intel SGX برای امنیت و برای الگوریتم اجماع PoET (فصل ۱۵) به کار رفته است. پروژهٔ 21 Bitcoin Computer بستری برای یادگیری و توسعهٔ اپلیکیشن بیت‌کوین بود.
• روش‌های صوری و امنیت: راستی‌آزمایی و آزمون قراردادها پیش از استقرار (Why3 برای Solidity)؛ Hawk برای محرمانگی قرارداد هوشمند.
• جایگزین‌هایی برای بلاک‌چین: Corda در واقع بلاک‌چین نیست؛ به‌جای بلاک شامل تراکنش‌ها، بر «شیء حالت» (state object) تکیه دارد که طبق قواعد شرکت‌کنندگان در شبکه جابه‌جا می‌شود. IOTA از یک گراف جهت‌دار بدون دور (DAG) به نام Tangle استفاده می‌کند و ادعا می‌شود مقیاس‌پذیری و حتی مقاومت در برابر حملات کوانتومی دارد. نویسنده یادآور می‌شود بیت‌کوین هم تا حدی در برابر حمله کوانتومی ایمن است، چون این حملات فقط به کلیدهای عمومیِ فاش‌شده کارگر است و کلید عمومی تا زمان خرج‌کردن از آدرس فاش نمی‌شود؛ با استفاده از آدرس جدید برای هر تراکنش خطر کم می‌شود و تغییر به الگوریتم امضای مقاوم کوانتومی هم نسبتاً ساده است.
• تلاش‌های interoperability: Qtum با هر دو بلاک‌چین بیت‌کوین و اتریوم سازگار است: از مدل UTXO بیت‌کوین برای انتقال ارزش و از EVM برای قرارداد هوشمند استفاده می‌کند؛ پروژه‌های اتریوم بدون تغییر قابل انتقال‌اند.
• بلاک‌چین به‌عنوان سرویس (BaaS): مثل Microsoft Azure (اتریوم به‌عنوان سرویس) و IBM Bluemix. نمونهٔ دیگر eGaaS (Electronic Government as a Service) با بلاک‌چین‌های ویژه برای وظایف حاکمیتی و کاهش گردش اسناد و بوروکراسی.
• کاهش مصرف برق: PoW بسیار ناکارآمد است و جز تأمین امنیت سودی ندارد؛ توجه به راه‌حل‌های سبزتر مانند PoS افزایش یافته، به‌ویژه با برنامهٔ اتریوم.

چالش‌های دیگر

بجز امنیت و حریم خصوصی (فصل ۱۸)، موانعی مانند مقررات، کنترل دولت‌ها، نابالغی فناوری، یکپارچه‌سازی با سیستم‌های موجود و هزینهٔ پیاده‌سازی باید حل شوند.

مقررات‌گذاری (Regulation)

• هیچ دولتی رمزارز را پول قانونی نمی‌شناسد؛ در آمریکا و آلمان در مواردی به‌عنوان پول طبقه‌بندی شده، اما پذیرش کامل فاصله دارد. هیچ نهاد ناظر مالی هم بلاک‌چین را به‌عنوان بستر مجاز مؤسسات مالی نپذیرفته است.
• بیت‌کوین عملاً بدون مقررات است. در بریتانیا طبق دستورالعمل VAT اتحادیهٔ اروپا از مالیات بر ارزش افزوده معاف است (ممکن است پس از Brexit تغییر کند)، ولی مالیات سود سرمایه (CGT) ممکن است اعمال شود. اعلام FCA بریتانیا مبنی بر احتمال تأیید شرکت‌های بلاک‌چینی نشانهٔ تنظیم‌گری نزدیک است.
• نگرانی عمومی دربارهٔ آماده‌نبودن برای تولید، به‌ویژه در مالی و سلامت؛ ولی نمونه‌هایی مثل ASX نشان می‌دهند وضعیت سریع عوض می‌شود.
• گزارش ENISA (آژانس امنیت شبکه و اطلاعات اتحادیهٔ اروپا) نگرانی‌هایی را برجسته کرده: مدیریت قرارداد هوشمند، مدیریت کلید، AML، ابزارهای ضدتقلب، و نیاز به مقررات، حسابرسی، کنترل و حاکمیت.
• یکپارچه‌سازی با سیستم‌های قدیمی (legacy) نگرانی اصلی است و موانع پذیرش عمدتاً مقرراتی، امنیتی و interoperability است.

سمت تاریک (Dark side)

مقاومت در برابر سانسور و تمرکززدایی همان ویژگی‌هایی‌اند که امکان سوءاستفادهٔ مجرمان را فراهم می‌کنند: محتوای غیرقانونی روی اینترنت با مراجعه به مراجع و ارائه‌دهندگان خدمات قابل حذف است، اما چیزی که روی بلاک‌چین ثبت شد تقریباً برگشت‌ناپذیر است. مثال: Silk Road که مواد مخدر را با بیت‌کوین و Dark Web (آدرس‌های onion از طریق Tor) می‌فروخت؛ با آنکه پس از ماه‌ها تلاش بسته شد، نمونه‌های مشابه پدید آمد. اگر سایتی غیرقانونی روی IPFS و بلاک‌چین باشد حذفش تقریباً ناممکن است. ابزارهای ناشناس‌سازی کامل مانند Zcash برای مجرمان لایهٔ حفاظتی اضافه می‌کنند، هرچند در موارد مشروع (مثلاً سوابق بیماران) مفیدند.

نظر نویسنده دربارهٔ تنظیم‌گری: ابتدا وضع قانون و سپس انتظار تطبیق فناوری ممکن است نوآوری را مختل کند؛ بهتر است مانند اینترنت اول رشد کند و در رسیدن به «جرم بحرانی»، نهادهای حاکم مقرراتی اعمال کنند. راه‌حل‌های پیشنهادی:

• ربات‌ها یا عامل‌های خودمختار / قراردادهای حاوی منطق نظارتی که تنظیم‌گران و مجریان قانون برنامه‌ریزی می‌کنند و روی بلاک‌چین برای حاکمیت و کنترل زندگی می‌کنند؛ مثلاً هر قرارداد هوشمند باید از «قرارداد کنترل‌کننده» عبور کند که منطق آن را بررسی کند.
• بازرسی کد قرارداد توسط تنظیم‌گر و صدور گواهی؛ شبیه امضای کد (code signing) برای فایل‌های اجرایی. این بیشتر برای بلاک‌چین‌های نیمه‌خصوصی/تنظیم‌شده مناسب است و نیازمند اعتماد به شخص ثالث است که با تمرکززدایی کامل در تضاد است؛ نویسنده پیشنهاد می‌کند خود بلاک‌چین بتواند صدور گواهی و امضای دیجیتال را به‌صورت غیرمتمرکز، شفاف و امن ارائه دهد.

پژوهش در بلاک‌چین

موضوعات برگزیدهٔ پژوهشی:

• قراردادهای هوشمند: پیشرفت در تعریف نیازمندی‌ها و قالب‌ها شده، ولی ایمن‌تر و امن‌تر کردن آن‌ها نیازمند پژوهش بیشتر است.
• مسائل تمرکز: به‌ویژه تمرکز استخراج در بیت‌کوین و چگونگی غیرمتمرکز کردن دوبارهٔ آن.
• محدودیت‌های توابع رمزنگاری: بیت‌کوین رمزنگاری بسیار مطمئنی دارد، اما موضوعاتی مانند تولید/استفادهٔ مجدد از nonce یکسان در امضای ECDSA (که منجر به بازیابی کلید خصوصی می‌شود)، برخورد (collision) در توابع هش، و حملات کوانتومی همچنان زمینهٔ پژوهش‌اند.
• الگوریتم‌های اجماع: مصرف برق بیت‌کوین تا پایان ۲۰۱۸ حدود ۱۲۵ TWh (تقریباً معادل کشور اسرائیل) پیش‌بینی می‌شود. پیشنهادها: استفاده از توان شبکه برای حل مسائل علمی/ریاضی، یا جایگزین‌هایی مانند PoS (مثل Casper در اتریوم). با این حال PoW هنوز بهترین گزینه برای تأمین امنیت بلاک‌چین عمومی است.
• مقیاس‌پذیری: نیاز به پژوهش در مقیاس‌پذیری درون‌زنجیره‌ای و بهبود راه‌حل‌های برون‌زنجیره‌ای (کانال‌های حالت). پیشنهادها: بزرگ‌تر کردن بلاک، یا بلاک‌چین‌های «بدون بلاک» مانند IOTA Tangle که تراکنش‌ها را در DAG نگه می‌دارد و از انتظار ~۱۰ دقیقه‌ای بیت‌کوین رها است.
• مبهم‌سازی کد (IO): هنوز عملی نیست و به پژوهش جدی نیاز دارد.

پروژه‌های برجسته

ابزارهای متفرقه

• افزونهٔ Solidity برای Visual Studio: IntelliSense، تکمیل خودکار و قالب برای DApp.
• MetaMask: مرورگر DApp (افزونهٔ Chrome) که بدون اجرای گره کامل اتریوم DAppها را اجرا می‌کند.
• Stratis: پلتفرم ساخت بلاک‌چین خصوصی با C# و .NET، متصل به زنجیرهٔ Stratis؛ از طریق Azure به‌عنوان BaaS.
• Embark: چارچوب توسعهٔ اتریوم مشابه Truffle؛ استقرار خودکار قرارداد، یکپارچگی با JavaScript و IPFS؛ نصب با npm.
• DAPPLE: مدیریت بسته، ساخت قرارداد و اسکریپت استقرار.
• Meteor: چارچوب full-stack برای برنامه‌های تک‌صفحه‌ای که برای DApp اتریوم هم قابل استفاده است.
• uPort: مدیریت هویت غیرمتمرکز روی اتریوم، با کنترل کاربر بر هویت و اطلاعات و سیستم اعتبار که کاربران یکدیگر را تأیید می‌کنند.
• INFURA: گره‌های سازمانی اتریوم و IPFS و لایهٔ سرویس Ferryman برای مسیریابی و توزیع بار.

همگرایی با صنایع دیگر

IoT + بلاک‌چین: اصالت، یکپارچگی، حریم خصوصی و ماهیت اشتراکی بلاک‌چین به IoT کمک می‌کند. تصویر: شبکهٔ IoT که روی بلاک‌چین اجرا می‌شود و با شبکهٔ مش غیرمتمرکز، ارتباط ماشین‌به‌ماشین (M2M) بلادرنگ دارد.

هوش مصنوعی: AI به داده‌های معتبر برای یادگیری ماشین نیاز دارد. وقتی تولیدکنندگان و مصرف‌کنندگان روی بلاک‌چین‌اند، دادهٔ حاصل از تعامل آن‌ها با تضمین اصالت به موتورهای یادگیری می‌رسد. اگر دستگاه IoT هک شود، چون خودش گرهٔ بلاک‌چین است و تحت مشوق‌ها، رد تراکنش نامعتبر و راستی‌آزمایی سخت قرار دارد، شبکه آن را گرهٔ بیزانتین تلقی می‌کند و آسیبی نمی‌زند. ترکیب اوراکل‌های هوشمند، قراردادهای هوشمند و AAها می‌تواند AIDAO (سازمان خودمختار غیرمتمرکز با هوش مصنوعی) بسازد که به‌جای انسان سازمان را اداره می‌کند؛ تحقق این چشم‌انداز به پژوهش بیشتر نیاز دارد. AAها در محیط «هوش مصنوعی توزیع‌شده» (DAI) فراهم‌شده توسط بلاک‌چین با یادگیری ماشین یاد می‌گیرند.

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

آینده

۲۰۱۷ سالی پیش‌بینی می‌شد که بلاک‌چین از اثبات مفهوم به تولید برسد؛ تا حدی پروژه‌های آزمایشی اجرا شد اما پیاده‌سازی تولیدی در مقیاس بزرگ هنوز دیده نشده بود. انتظار می‌رفت در ۲۰۱۸ برخی سازمان‌ها پروژه‌های تمام‌مقیاس را اجرا کنند و در ۲۰۱۹ حدود ۲۰٪ بانک‌های مرکزی از بلاک‌چین استفاده کنند.

پیش‌بینی‌های نویسنده برای بازهٔ ۲۰۲۰ تا ۲۰۵۰:

• IoT روی چند بلاک‌چین اجرا می‌شود و اقتصاد M2M (انرژی، خودروهای خودران، لوازم خانگی) شکل می‌گیرد.
• سوابق پزشکی بین بلاک‌چین‌های خصوصی کنسرسیوم‌های ارائه‌دهندگان سلامت (احتمالاً یک بلاک‌چین مشترک برای داروخانه، بیمارستان و کلینیک) با حفظ حریم بیمار به اشتراک گذاشته می‌شود.
• انتخابات با برنامه‌های وب غیرمتمرکز و پشت‌صحنهٔ بلاک‌چین برگزار می‌شود.
• مؤسسات مالی بلاک‌چین‌های خصوصی متعدد، و نیمه‌خصوصی برای هویت در AML و KYC را در سطح جهان به اشتراک می‌گذارند.
• مهاجرت و کنترل مرزی روی بلاک‌چین مشترک بین مرزها ثبت و کنترل پاسپورت انجام می‌شود.
• دولت‌ها بلاک‌چین بین‌ادارات برای مستمری، مزایا، ثبت املاک و ثبت تولد می‌سازند تا حسابرس‌پذیری و اعتماد بالا رود.
• پژوهش در رمزنگاری و سیستم‌های توزیع‌شده به اوج می‌رسد و دانشگاه‌ها دوره‌هایی دربارهٔ رمزاقتصاد، رمزارز و بلاک‌چین دارند.
• AIDAOها بر بلاک‌چین‌ها رایج می‌شوند.
• بلاک‌چین عمومی تنظیم‌شده‌ای توسط دولت برای کارهای روزمره (مالیات، ثبت ازدواج، مجوز تلویزیون) استفاده می‌شود.
• BaaS مانند خدمتی استاندارد در دسترس همه است و بلاک‌چین مانند اینترنت بی‌صدا در زندگی ادغام می‌شود.
• مدیریت حقوق دیجیتال (DRM) برای هنر و رسانه با ارتباط مستقیم تولیدکننده و مصرف‌کننده و حذف واسطهٔ مرکزی.
• رمزارزهایی مانند بیت‌کوین ارزش‌شان رشد می‌کند (نویسنده حتی «ده‌ها هزار دلار» می‌گوید)، سرمایه‌گذاری رمزارزی زیاد شده و جامعهٔ رمزاقتصادی جدید پدید می‌آید.
• هویت دیجیتال روی بلاک‌چین مدیریت می‌شود؛ رأی‌گیری، مالیات و پرداخت وجوه از طریق بلاک‌چین.
• مؤسسات مالی و clearing houseها در ۲۰۱۸ راه‌حل‌های بلاک‌چینی برای مشتریان ارائه می‌کنند.

(این‌ها پیش‌بینی‌های شخصی نویسنده در سال انتشار کتاب‌اند، نه حقایق قطعی.)

جمع‌بندی

نویسنده معتقد است انقلاب بلاک‌چین آغاز شده و با شتاب نمایی رشد می‌کند. در این فصل روندهایی مانند بلاک‌چین‌های ویژهٔ کاربرد، سازمانی و خصوصی، استانداردسازی، کنسرسیوم‌ها، BaaS و گذار از PoW به سمت PoS بررسی شد؛ همچنین چالش‌های مقررات‌گذاری و «سمت تاریک» (محتوای غیرقابل‌حذف و فعالیت مجرمانه) و راه‌حل‌های احتمالی مثل قراردادهای ناظر یا گواهی کد. فهرست موضوعات پژوهشی (امنیت قرارداد، تمرکز استخراج، رمزنگاری، اجماع، مقیاس‌پذیری، IO)، پروژه‌های برجسته و ابزارهای توسعه ارائه شد و همگرایی با IoT و AI و پیش‌بینی‌های ۲۰۲۰ تا ۲۰۵۰ پایان‌بخش فصل بود. پیام نهایی کتاب: بلاک‌چین ظرفیت تغییر جهان را دارد و بخشی از نشانه‌ها مانند موفقیت نمونه‌های اثبات مفهوم و افزایش توسعه‌دهندگان دیده می‌شود، و بلاک‌چین‌ها مانند اینترنت وارد زندگی ما خواهند شد.