فرض کنیم برای کسی بیت کوین فرستاده‌ایم و می‌خواهیم اطمینان پیدا کنیم تراکنش در شبکه ثبت شده است. در مرورگر بلاکچین با چند چیز روبه‌رو می‌شویم: شماره بلاک، هش بلاک و شناسه تراکنش. این‌ها فقط چند کد عجیب نیستند؛ هرکدام کمک میکنند بفهمیم اطلاعات کجا قرار گرفته و چطور میشود درستی آن را بررسی کرد.
ساختار داده در بلاکچین دقیقا درباره همین نظم است. تراکنشها در بلاک‌ها ثبت می‌شوند، بلاک‌ها با ارجاع‌های رمزنگاری‌شده به یکدیگر وصل می‌شوند و گره‌های شبکه داده‌ها را طبق قواعد مشترک بررسی میکنند. برای فهمیدن این سازوکار لازم نیست برنامه‌نویس باشیم. کافی است سه موضوع را از هم جدا کنیم: تاریخچه تراکنشها، وضعیت فعلی دارایی‌ها و قواعدی که مشخص میکنند کدام بلاک پذیرفته شود.
ساختار داده در بلاکچین دقیقا چیست؟
یک پایگاه داده معمولی می‌تواند با اجازه مدیر یا برنامه، رکوردی را تغییر دهد. در بسیاری از بلاکچین‌های عمومی، ماجرا متفاوت است: تراکنش‌های پذیرفته‌شده به ترتیب در بلاک‌ها قرار می‌گیرند و هر بلاک به بلاک پیش از خودش ارجاع می‌دهد. اگر کسی بخواهد اطلاعات قدیمی را پنهانی عوض کند، این ارتباط‌های رمزنگاری‌شده به هم می‌ریزند. البته امنیت فقط از این پیوندها نمی‌آید؛ قواعد اعتبارسنجی و اجماع شبکه هم نقش اساسی دارند.
یک بلاک چه اطلاعاتی نگه می‌دارد؟
بلاک را مثل یک بسته از اطلاعات مرتبط تصور کنیم. برای توضیح ساده‌تر، می‌توانیم در بیت کوین آن را به دو بخش تقسیم کنیم: هدر یا سرآیند که اطلاعات شناسایی و ارجاع‌ها را نگه می‌دارد، و بدنه که تراکنشها در آن قرار می‌گیرند. این مدل برای فهم موضوع مفید است، ولی همه شبکه‌ها دقیقا همین فیلدها و همین شکل پیاده‌سازی را ندارند.
بدنه بلاک چیست؟
بدنه همان جایی است که معمولا فهرست تراکنش‌های بلاک را پیدا می‌کنیم. بسته به پروتکل، ممکن است دادههای دیگری هم در آن باشد. ترتیب تراکنشها مهم است، چون گرهها باید بتوانند اطلاعات بلاک را طبق قواعد یکسان بررسی کنند. پس اگر در هدر یک مقدار خلاصه مثل ریشه مرکل می‌بینیم، نباید تصور کنیم متن کامل همه تراکنشها هم داخل هدر ذخیره شده است.
هدر یا سرآیند بلاک چیست؟
هدر را می‌توانیم شناسنامه فنی بلاک بدانیم. مثلا در بیت کوین، هدر شامل نسخه، هش بلاک قبلی، ریشه مرکل تراکنشها، زمان، هدف سختی شبکه و نانس است. این اطلاعات برای پیوند دادن بلاک‌ها و بررسی قواعد اثبات کار کاربرد دارند. نکته اینجاست که نمی‌توانیم همین فهرست را بدون تغییر برای اتریوم یا هر بلاکچین دیگری به کار ببریم.
| بخش یا فیلد | نقش ساده در ساختار بلاک |
|---|---|
| هش بلاک قبلی | بلاک جدید را به سابقه قبل از خود مرتبط میکند. |
| ریشه مرکل | به مجموعه تراکنش‌های داخل بلاک تعهد رمزنگاری شده می‌دهد. |
| زمان و شناسه‌های پروتکلی | زمینه لازم برای ترتیب، شناسایی و بررسی قواعد را فراهم میکند. |
| داده تراکنشها | محتوایی است که شبکه باید مطابق قواعد خود بررسی کند. |
هش بلاک چیست و چه فرقی با شناسه تراکنش دارد؟
تابع هش از داده ورودی، خروجی‌ای با طول ثابت می‌سازد. اگر حتی بخش کوچکی از ورودی تغییر کند، معمولا هش هم کاملا متفاوت میشود. در بیت کوین، هش بلاک از هدر بلاک محاسبه میشود و برای شناسایی آن به کار می‌رود. اما شناسه تراکنش یا TXID به یک تراکنش مشخص مربوط است. پس هش بلاک و TXID را نباید یکی بدانیم؛ هرکدام داده و کاربرد خودش را دارد.
چرا بلاک‌ها به یکدیگر متصل می‌شوند؟
فرض کنیم بلاک دوم، هش بلاک اول را در هدر خودش ثبت کرده است. حالا اگر اطلاعات بلاک اول تغییر کند، هش آن هم عوض میشود و ارجاع موجود در بلاک دوم دیگر با نسخه جدید جور درنمی‌آید. برای همین دستکاری تاریخچه پذیرفته‌شده فقط تغییر یک رکورد نیست؛ باید از ارتباط بلاک‌های بعدی و قواعد پذیرش شبکه هم عبور کرد.
با این حال، بهتر است «دستکاری دشوار» را با «هرگز تغییر نمی‌کند» اشتباه نگیریم. گاهی دو شاخه رقیب از بلاک‌ها برای مدتی در شبکه دیده می‌شوند و بعد یکی کنار می‌رود. میزان اطمینان به ثبت یک تراکنش به سازوکار اجماع، تعداد تاییدها یا معیار نهایی شدن همان شبکه بستگی دارد. صرف دیدن هش یک بلاک، تضمین قطعی بودن تراکنش نیست.
درخت مرکل چیست و چرا در بلاکچین استفاده میشود؟
حالا یک بلاک با تراکنش‌های زیاد را در نظر بگیریم. اگر بخواهیم بفهمیم تراکنش مشخصی داخل آن بوده یا نه، لازم نیست همیشه تک‌تک تراکنشها را دوباره دریافت کنیم. درخت مرکل کمک میکند چنین بررسی‌ای با تعداد محدودی هش انجام شود.
در نمونه بیت کوین، ابتدا شناسه تراکنشها با ترتیب مشخص در پایین درخت قرار می‌گیرند. سپس هش‌ها به‌صورت جفتی ترکیب و دوباره هش می‌شوند تا در نهایت به یک مقدار به نام ریشه مرکل برسیم. این ریشه در هدر بلاک ثبت میشود. اگر مسیر هش‌های لازم را داشته باشیم، می‌توانیم حضور یک تراکنش در مجموعه متعهدشده را بررسی کنیم؛ به شرط اینکه ریشه و هدر بلاک را معتبر بدانیم.
این ساختار هم در همه شبکه‌ها یکسان نیست. برای نمونه، اتریوم در لایه اجرای خود از ساختارهای درختی خانواده مرکل پاتریشیا برای تعهد به وضعیت، تراکنشها و رسیدها استفاده میکند. کاربرد کلی مشترک است، اما شکل ذخیره‌سازی و روش اثبات می‌تواند فرق کند.
دفترکل توزیع شده چه فرقی با پایگاه داده معمولی دارد؟
در یک پایگاه داده متمرکز، معمولا یک مجموعه مشخص اختیار اصلی ثبت و تغییر اطلاعات را دارد. در دفترکل توزیع‌شده، چند مشارکت‌کننده می‌توانند نسخه‌ای از سوابق را نگه دارند و با قواعد مشخص درباره تغییرات به توافق برسند. بلاکچین یکی از روش‌های پیاده‌سازی دفترکل توزیع‌شده است، نه اسم دیگری برای هر پایگاه داده توزیع‌شده. تفاوت اصلی فقط تعداد رایانه‌ها نیست؛ مهم است چه کسی می‌تواند داده را بررسی کند و شبکه چگونه بر سر نسخه پذیرفته‌شده به توافق می‌رسد.
موجودی رمزارزها چگونه در ساختار داده ثبت میشود؟
تا اینجا بیشتر درباره تاریخچه تراکنشها حرف زدیم. اما وقتی کیف پول موجودی را نشان می‌دهد، باید مشخص باشد در همین لحظه چه دارایی‌ای قابل خرج کردن است. همه شبکه‌ها این وضعیت را به یک شکل نگه نمی‌دارند. برای روشن شدن تفاوت، دو نمونه مهم را کنار هم بگذاریم: مدل UTXO در بیت کوین و مدل حساب در اتریوم.
مدل UTXO در بیت کوین چیست؟
UTXO مخفف خروجی خرج‌نشده تراکنش است. در بیت کوین، به‌جای اینکه فقط یک عدد به نام موجودی در یک حساب داشته باشیم، مجموعه‌ای از خروجی‌های خرج‌نشده را در نظر می‌گیریم. تراکنش جدید می‌تواند یک یا چند خروجی قبلی را مصرف کند و خروجی‌های تازه‌ای بسازد. اگر ارزش ورودی بیشتر از مبلغی باشد که می‌فرستیم، معمولا بخشی از آن به‌عنوان باقی‌مانده در خروجی تازه‌ای برمی‌گردد.
بیایید با یک مثال فرضی حساب کنیم: یک خروجی قابل خرج به ارزش ۰٫۱ بیت کوین داریم و می‌خواهیم ۰٫۰۶ بیت کوین بفرستیم. اگر کارمزد فرضی را ۰٫۰۰۱ بیت کوین در نظر بگیریم، می‌توانیم یک خروجی ۰٫۰۶ برای گیرنده و یک خروجی ۰٫۰۳۹ برای باقی‌مانده داشته باشیم. جمع خروجی‌ها و کارمزد میشود همان ۰٫۱ بیت کوین ورودی. این اعداد فقط برای آموزش‌اند و کارمزد واقعی شبکه را نشان نمی‌دهند.
مدل حساب در اتریوم چیست؟
اتریوم در لایه اجرا از مدل مبتنی بر حساب استفاده میکند. هر حساب وضعیت مشخصی دارد؛ مثلا موجودی اتر و شمارنده تراکنش یا nonce. حساب‌های قرارداد هوشمند علاوه بر این‌ها به کد و دادههای ذخیره‌شده هم مربوط می‌شوند. وقتی تراکنشی اجرا میشود، شبکه تغییر وضعیت حساب‌های درگیر را محاسبه و طبق قواعد خود بررسی میکند. بنابراین برای فهم موجودی در این مدل، به وضعیت فعلی حساب نگاه می‌کنیم، نه جمع خروجی‌های خرج‌نشده.
| معیار | مدل UTXO در بیت کوین | مدل حساب در اتریوم |
|---|---|---|
| داده اصلی برای محاسبه دارایی | خروجی‌های خرج نشده | وضعیت حساب و موجودی |
| اثر تراکنش | مصرف خروجی‌های قبلی و ساخت خروجی تازه | به‌روز شدن وضعیت حساب‌ها پس از اجرا |
| شیوه فهم موجودی | جمع خروجی‌های قابل خرج | خواندن موجودی از وضعیت فعلی حساب |
| نکته مهم | خروجی‌ها می‌توانند جداگانه مصرف شوند | حساب قراردادی علاوه بر موجودی، کد و داده دارد |
تفاوت تاریخچه تراکنش و وضعیت جاری شبکه چیست؟
تاریخچه به ما می‌گوید چه تراکنش‌هایی و به چه ترتیبی در بلاک‌های پذیرفته‌شده ثبت شده‌اند. وضعیت فعلی نتیجه اجرای آن تراکنش‌هاست؛ مثلا کدام خروجی‌های بیت کوین هنوز خرج نشده‌اند یا موجودی یک حساب اتریوم چقدر است. به زبان ساده، تاریخچه می‌گوید «چه اتفاقی افتاده» و وضعیت می‌گوید «نتیجه آن تا این لحظه چیست». برای رسیدن به نتیجه درست، قواعد پردازش تراکنشها هم لازم‌اند.
در لایه اجرای اتریوم، ریشه وضعیت یا state root تعهد رمزنگاری‌شده به وضعیت حاصل از اجرای تراکنش‌هاست. ریشه تراکنشها و ریشه رسیدها کار دیگری انجام می‌دهند. هیچ‌کدام از این ریشه‌ها به‌تنهایی یک نسخه قابل خواندن از تمام دادههای شبکه نیستند؛ برای بازیابی جزییات به دادههای مربوط و روش بررسی آن‌ها نیاز داریم.
در مرورگر بلاکچین چه اطلاعاتی را بررسی کنیم؟
برای اینکه این مفاهیم فقط در حد توضیح نمانند، می‌توانیم در مرورگر بلاکچین همان شبکه، صفحه یک بلاک و یکی از تراکنش‌های آن را باز کنیم. در نگاه اول این موارد را از هم تشخیص بدهیم:
- ارتفاع یا شماره بلاک: جای آن بلاک را در زنجیره نشان می‌دهد.
- هش بلاک و ارجاع به بلاک قبلی: کمک میکند پیوند بلاک‌ها را بررسی کنیم.
- شناسه تراکنش (TXID): برای پیدا کردن یک تراکنش مشخص به کار می‌رود.
- وضعیت تراکنش و تاییدها: نشان می‌دهد تراکنش چطور ثبت شده و از دید همان شبکه چقدر تایید گرفته است.
ممکن است بعضی مرورگرها فیلدهای فنی بیشتری نمایش بدهند. نبود یک فیلد در صفحه مرورگر الزاما به این معنی نیست که آن داده در پروتکل وجود ندارد.
سه برداشت اشتباه درباره دادههای بلاکچین
- ریشه مرکل همان متن فشرده تراکنش‌هاست: ریشه مرکل یک مقدار رمزنگاری‌شده است، نه نسخه کوچکی از اطلاعات که بتوانیم متن تراکنشها را از آن بیرون بکشیم. برای دیدن داده اصلی به اطلاعات جداگانه نیاز داریم.
- هر چیزی در مرورگر بلاکچین می‌بینیم، داخل بلاک ذخیره شده است: بعضی مرورگرها برچسب‌ها یا توضیحاتی را از منابع بیرون زنجیره نشان می‌دهند. باید داده ثبت‌شده در پروتکل را از اطلاعاتی که سرویس به آن اضافه کرده جدا کنیم.
- وجود هش یعنی امنیت صددرصدی: هش و اتصال بلاک‌ها مهم‌اند، اما امنیت شبکه به اعتبار امضاها، قواعد اجماع، نرم‌افزار گرهها و روش نگهداری کلید خصوصی هم بستگی دارد.
جمع بندی
اگر بخواهیم تصویر کلی را به خاطر بسپاریم، بلاک تراکنشها را در یک ساختار مشخص کنار هم می‌گذارد، هش و هدر ارتباط و بررسی بلاک‌ها را ممکن میکنند و ریشه مرکل برای اثبات حضور داده به کار می‌آید. از طرف دیگر، مدل‌هایی مثل UTXO و حساب مشخص میکنند نتیجه تراکنشها چطور به وضعیت دارایی‌ها تبدیل شود. با این تفکیک، وقتی در مرورگر بلاکچین هش، ریشه یا موجودی می‌بینیم، بهتر می‌فهمیم هرکدام دقیقا چه چیزی را نشان می‌دهند.
سوالات متداول
۱. آیا هش بلاک با شناسه تراکنش یکی است؟
خیر. هش بلاک به شناسه رمزنگاری شده یک بلاک اشاره میکند، اما شناسه تراکنش به خود تراکنش تعلق دارد. روش محاسبه و کاربرد این دو در هر شبکه به قواعد همان پروتکل بستگی دارد.
۲. آیا تمام بلاکچینها دقیقا از درخت مرکل بیت کوین استفاده میکنند؟
خیر. درخت مرکل یکی از خانوادههای ساختارهای مبتنی بر هش است. برای نمونه، اتریوم در لایه اجرای خود برای ثبت وضعیت، تراکنشها و رسیدها از ساختارهای درختی دیگری نیز استفاده میکند.
۳. اگر یک گره دادههای قدیمی را از حافظه محلی حذف کند، تاریخچه بلاکچین عوض میشود؟
نه لزوما. بعضی گرهها برای مدیریت فضای ذخیره، بخشی از دادههای محلی را هرس میکنند؛ این کار به خودی خود تاریخچه پذیرفته شده شبکه را تغییر نمیدهد. نوع داده قابل بازیابی به طراحی گره و شبکه بستگی دارد.
۴. آیا اثبات حضور تراکنش در بلاک به معنی نهایی شدن آن است؟
خیر. اثبات حضور، قرار داشتن یک تراکنش در یک بلاک مشخص را بررسی میکند. درجه قطعیت آن بلاک و احتمال بازآرایی زنجیره به قواعد اجماع و وضعیت شبکه وابسته است.
