بلاکچین مجوزمحور یا Permissioned Blockchain نوعی شبکه بلاکچینی است که در آن همه نقش‌ها و سطح‌های دسترسی برای هر کاربر یا سازمان یکسان نیست. عضویت در شبکه، اجرای نود، ارسال تراکنش، مشاهده بخشی از داده‌ها، تأیید تراکنش یا مشارکت در اجماع می‌تواند به مجوز، هویت تأییدشده و سیاست‌های حاکمیتی وابسته باشد. همین ویژگی باعث شده این مدل بیشتر در سناریوهایی مطرح شود که چند سازمان می‌خواهند روی یک دفترکل مشترک کار کنند، اما نمی‌خواهند همه چیز برای عموم باز باشد.
در تعریف فنی، «مجوزمحور» با «خصوصی» کاملاً مترادف نیست. یک شبکه Permissioned می‌تواند توسط یک سازمان یا توسط چند سازمان مستقل اداره شود و حتی بخشی از داده های آن برای عموم قابل مشاهده باشد. از طرف دیگر، اصطلاح Private Blockchain معمولاً به شبکه‌ای اشاره می‌کند که مشارکت و دسترسی آن برای گروه محدودی بسته است. برای درک جایگاه این مدل در کل اکوسیستم، ابتدا مقاله انواع بلاکچین را می‌توان به‌عنوان نقشه کلی طبقه‌بندی در نظر گرفت؛ این صفحه به‌صورت تخصصی فقط روی مدل Permissioned تمرکز دارد.
در یک بلاکچین Permissioned، عضویت و اختیارات شبکه بر اساس یک مدل هویتی و مجموعه‌ای از Policyها تعیین می‌شود. این سیاست‌ها مشخص می‌کنند چه کسی عضو معتبر است، چه نهادی می‌تواند نود اجرا کند، چه کسانی مجاز به ثبت یا تأیید تراکنش هستند و چه داده‌هایی برای کدام شرکت‌کننده قابل مشاهده است. بنابراین تفاوت اصلی فقط در «بسته بودن شبکه» نیست؛ مسئله اصلی این است که حق انجام عملیات شبکه از قبل تعریف و کنترل می‌شود.
NIST در مرور فنی بلاکچین، شبکه‌ها را از نظر مدل مجوز به Permissionless و Permissioned تقسیم می‌کند. در مدل Permissioned، مشارکت در نگهداری یا انتشار بلاک‌ها به کاربران مجاز محدود می‌شود و شبکه می‌تواند دسترسی خواندن یا ارسال تراکنش را نیز محدود کند. این تعریف نشان می‌دهد که Permissioned بودن بیشتر درباره «حقوق مشارکت» است تا صرفاً عمومی یا خصوصی بودن رابط کاربری.
اگر هنوز با اجزای پایه این فناوری مانند دفترکل توزیع شده، بلوک، نود و قواعد اعتبارسنجی آشنا نیستید، مقاله بلاکچین چیست؟ پیش نیاز مناسب تری برای شروع است.
سه اصطلاح Public، Private و Permissioned اغلب در منابع عمومی به‌جای یکدیگر استفاده می‌شوند، اما بهتر است آن‌ها را روی محورهای جداگانه ببینیم: دسترسی به شبکه، مشاهده داده، اجرای نود، اعتبارسنجی، صدور هویت و حاکمیت.
| ویژگی | Permissioned Blockchain | Public / Permissionless Blockchain | Private Blockchain |
|---|---|---|---|
| عضویت | معمولاً نیازمند تأیید یا هویت معتبر | عموماً بدون تأیید یک مدیر مرکزی | برای گروه محدود یا سازمان مشخص |
| نقش‌ها | قابل تعریف بر اساس Policy و Identity | طبق قواعد عمومی پروتکل | تحت کنترل اپراتور یا مدیران محدود |
| مشاهده داده | می‌تواند عمومی، محدود یا ترکیبی باشد | در بسیاری از شبکه‌ها عمومی است | معمولاً محدود |
| اجماع | میان شرکت‌کنندگان مجاز | میان مشارکت‌کنندگان آزاد طبق قواعد پروتکل | معمولاً بین مجموعه کوچک‌تری از نودها |
| حاکمیت | یک سازمان یا کنسرسیوم | جامعه، توسعه‌دهندگان و مشارکت‌کنندگان پروتکل | عموماً یک نهاد یا گروه محدود |
بنابراین هر Private Blockchain معمولاً Permissioned است، اما هر Permissioned Blockchain الزاماً یک شبکه تک‌سازمانی و کاملاً خصوصی نیست. برای مثال، چند شرکت مستقل می‌توانند در یک کنسرسیوم مشترک عضو باشند، هرکدام نودهای خود را اجرا کنند و درباره Policyهای شبکه به‌صورت مشترک تصمیم بگیرند.
در این شبکه‌ها معمولاً هویت دیجیتال نقطه شروع کنترل دسترسی است. برخلاف بسیاری از شبکه‌های عمومی که آدرس‌های رمزنگاری‌شده می‌توانند بدون ثبت هویت سازمانی فعالیت کنند، در یک شبکه سازمانی ممکن است هر کاربر، سرویس، نود یا سازمان با گواهی و نقش مشخص شناخته شود.
در مستندات رسمی Hyperledger Fabric درباره Membership Service Provider توضیح داده شده است که Fabric یک شبکه Permissioned است و شرکت‌کنندگان باید هویت قابل‌اعتبارسنجی داشته باشند. MSP تعیین می‌کند کدام هویت‌ها عضو معتبر یک سازمان هستند و چه نقش‌هایی می‌توانند در شبکه داشته باشند.
این مدل اجازه می‌دهد دسترسی‌ها در چند سطح تعریف شوند؛ برای مثال یک کاربر فقط مجاز به ارسال تراکنش باشد، یک Peer بتواند تراکنش‌ها را اجرا و اعتبارسنجی کند، و یک مدیر سازمان اجازه تغییر تنظیمات یا تأیید اعضای جدید را داشته باشد. همین جداسازی نقش‌ها یکی از تفاوت‌های مهم بلاکچین سازمانی با تصور ساده «همه نودها یکسان هستند» است.
برای درک دقیق‌تر تفاوت نقش نودها، صفحه نود در بلاکچین چیست؟ توضیح می‌دهد که Node، Validator و سایر نقش‌های شبکه الزاماً مترادف نیستند.
Permissioned بودن به معنی حذف اجماع نیست. شبکه همچنان باید درباره ترتیب و اعتبار تراکنش‌ها به توافق برسد، اما چون مجموعه شرکت‌کنندگان شناخته‌شده و محدودتر است، می‌تواند از الگوریتم‌ها و معماری‌هایی متفاوت از شبکه‌های عمومی استفاده کند.
به‌جای این فرض که همه شبکه‌های بلاکچینی باید از Proof of Work استفاده کنند، باید Consensus را متناسب با Threat Model و ساختار شبکه بررسی کرد. برخی شبکه‌های مجوزمحور از الگوریتم‌های Crash Fault Tolerant و برخی از مدل‌های Byzantine Fault Tolerant استفاده می‌کنند. در Fabric، سرویس Ordering می‌تواند بر پایه پیاده‌سازی‌هایی مانند Raft و BFT کار کند. توضیح عمومی‌تر درباره این تفاوت‌ها در مقاله الگوریتم اجماع بلاکچین آمده است.
مستندات رسمی Ordering Service در Hyperledger Fabric نیز نشان می‌دهد که Ordererها مسئول مرتب‌سازی تراکنش‌ها و ساخت بلاک‌ها هستند و Policyهای کانال بر دسترسی و تنظیمات شبکه اثر می‌گذارند. بنابراین در چنین معماری‌ای «ماینر» الزاماً نقشی ندارد و نباید بلاکچین مجوزمحور را با مدل استخراج در بیت‌کوین توضیح داد.
Hyperledger Fabric یکی از شناخته‌شده‌ترین چارچوب‌های متن‌باز برای ساخت شبکه‌های سازمانی و Permissioned است. برخلاف توضیح قدیمی که همه پروژه‌های Hyperledger را دارای یک معماری مشترک واحد معرفی می‌کرد، بهتر است Fabric را به‌عنوان یک پروژه مشخص با معماری ماژولار مستقل بررسی کنیم.
در سال ۲۰۲۶، صفحه رسمی Hyperledger Fabric در LF Decentralized Trust آن را یک پلتفرم دفترکل توزیع‌شده سازمانی و ماژولار معرفی می‌کند که برای شبکه‌های دارای هویت و کنترل دسترسی طراحی شده است. Fabric بخشی از اکوسیستم LF Decentralized Trust در Linux Foundation است.
اجزای کلیدی معماری Fabric را می‌توان به‌صورت خلاصه این‌گونه دید:
برای آشنایی مستقل با مفهوم قرارداد هوشمند، مقاله قرارداد هوشمند چیست؟ موضوع را بدون ورود به جزئیات اختصاصی Fabric بررسی می‌کند.
خیر. Permissioned بودن الزاماً به معنی محرمانه بودن تمام Ledger نیست. یک شبکه می‌تواند عضویت و حق اعتبارسنجی را محدود کند، اما بخشی از داده را برای کاربران بیشتری قابل خواندن نگه دارد. برعکس، ممکن است داده‌های حساس فقط میان چند سازمان خاص به اشتراک گذاشته شوند.
در Fabric، Channel و Private Data Collection برای طراحی چنین سطوحی از محرمانگی استفاده می‌شوند. در یک Private Data Collection، داده اصلی فقط میان Peerهای مجاز توزیع می‌شود و سایر اعضای کانال می‌توانند در صورت طراحی مناسب تنها اثر رمزنگاری‌شده یا Hash مربوط به آن داده را ببینند. این مدل برای سناریوهایی مناسب است که سازمان‌ها باید روی یک فرآیند مشترک توافق کنند اما نمی‌خواهند تمام اطلاعات تجاری، قیمت‌ها یا جزئیات قرارداد برای همه اعضا آشکار باشد.
Permissioned Blockchain راه‌حل «بهتر» برای همه پروژه‌ها نیست. در بسیاری از کاربردها یک پایگاه‌داده متمرکز ساده‌تر، ارزان‌تر و سریع‌تر است. بلاکچین زمانی معنا پیدا می‌کند که چند طرف مستقل به یک State مشترک نیاز داشته باشند اما نخواهند تمام کنترل را به یک دیتابیس متعلق به یک طرف بسپارند.
این مدل بیشتر زمانی مفید است که چند سازمان مستقل باید روی یک دفترکل مشترک توافق کنند و در عین حال هویت اعضا، دسترسی به داده و قواعد حاکمیت برای آن‌ها مهم باشد. نمونه‌های متداول شامل زنجیره تأمین، ثبت اسناد بین‌سازمانی، تسویه دارایی‌های توکنیزه‌شده، تبادل داده میان شرکت‌ها و فرآیندهای چندمرحله‌ای دارای ناظر یا حسابرس است.
برای مثال، در یک زنجیره تأمین می‌توان تولیدکننده، شرکت حمل‌ونقل، انبار و نهاد بازرسی را عضو یک شبکه کرد. هر عضو هویت و نقش مشخص دارد؛ بعضی داده‌ها مانند وضعیت حمل برای همه اعضا مشترک است، اما قرارداد قیمت یا اطلاعات محرمانه می‌تواند فقط برای طرف‌های مربوط قابل مشاهده باشد.
با این حال، اگر یک سازمان به‌تنهایی مالک همه داده‌ها و فرآیندهاست و هیچ طرف مستقلی نیاز به نگهداری یا اعتبارسنجی مشترک State ندارد، یک Database سنتی معمولاً معماری ساده‌تری خواهد بود. استفاده از واژه Blockchain به‌تنهایی دلیل کافی برای انتخاب این فناوری نیست.
وجود یک Permissioned Blockchain لزوماً به معنی وجود یک رمزارز عمومی و قابل معامله نیست. بسیاری از شبکه‌های سازمانی برای ثبت State، اسناد یا دارایی‌های داخلی طراحی می‌شوند و ممکن است هیچ Token عمومی نداشته باشند. بنابراین نباید ارزش فنی یک شبکه Permissioned را با قیمت یک دارایی در بازار یکی دانست.
اگر هدف کاربر بررسی دارایی‌های عمومی بازار است، مسیرهایی مانند قیمت ارز دیجیتال و خرید ارز دیجیتال موضوعی جدا از معماری Permissioned Blockchain دارند. همچنین انتخاب یک صرافی ارز دیجیتال به خدمات معاملاتی مربوط است و نباید با مدل حاکمیت شبکه بلاکچین اشتباه گرفته شود.
بلاکچین مجوزمحور شبکه‌ای است که عضویت، نقش‌ها و سطح دسترسی در آن بر اساس هویت و Policy کنترل می‌شود. این مدل می‌تواند تک‌سازمانی یا چندسازمانی باشد و ممکن است داده‌های عمومی و خصوصی را در کنار هم مدیریت کند. مهم‌ترین تفاوت آن با شبکه Permissionless این است که مشارکت در نقش‌های کلیدی شبکه آزاد و بدون مجوز نیست.
در ارزیابی یک Permissioned Blockchain باید به‌جای تمرکز بر برچسب «خصوصی»، چهار موضوع را جداگانه بررسی کرد: چه کسی عضو شبکه می‌شود، چه کسی داده را می‌بیند، چه کسی تراکنش‌ها را اعتبارسنجی می‌کند و چه نهادی Governance را کنترل می‌کند. Hyperledger Fabric نمونه مهمی از معماری سازمانی است که Identity، Membership، Policy، Peer، Ordering Service و سازوکارهای محرمانگی را به‌صورت ماژولار کنار هم قرار می‌دهد.
نه لزوماً. یک شبکه مجوزمحور می‌تواند تحت کنترل یک سازمان باشد، اما می‌تواند بین چند سازمان مستقل نیز توزیع شود. میزان تمرکز به نحوه توزیع نودها، حق رأی، مدیریت هویت، Policyهای تغییر شبکه و سازوکار اجماع بستگی دارد. بنابراین برچسب Permissioned به‌تنهایی مشخص نمی‌کند شبکه تا چه حد متمرکز یا غیرمتمرکز است.
خیر. وجود Token عمومی شرط یک Permissioned Blockchain نیست. بسیاری از شبکه‌های سازمانی برای ثبت اسناد، هماهنگی State یا اجرای فرایندهای بین‌سازمانی ساخته می‌شوند و ممکن است هیچ دارایی عمومی قابل معامله‌ای نداشته باشند. در برخی کاربردها نیز Token فقط داخل همان شبکه و با قوانین دسترسی مشخص استفاده می‌شود.
نمی‌توان یک رتبه‌بندی مطلق ارائه کرد. شبکه مجوزمحور می‌تواند با هویت‌های مشخص، کنترل دسترسی و تعداد محدود نودها سطح عملیاتی قابل‌کنترلی داشته باشد، اما در مقابل به Governance، مدیریت کلیدها و مجموعه اعتبارسنج‌های خود وابسته است. شبکه عمومی Threat Model متفاوتی دارد. امنیت باید بر اساس مدل تهدید، توزیع نودها، اجماع، مدیریت کلید و امکان تبانی بررسی شود.
باید مشخص شود چرا چند طرف مستقل به یک Ledger مشترک نیاز دارند و چرا یک Database تحت مدیریت یک طرف کافی نیست. اگر مسئله واقعی اعتماد بین چند سازمان، اشتراک State، ثبت قابل‌ردیابی و اعمال Policyهای مشترک باشد، Permissioned Blockchain می‌تواند گزینه مناسبی باشد؛ در غیر این صورت ممکن است پیچیدگی بلاکچین توجیه فنی نداشته باشد.
