برنامه Spring Boot Full stack Blockchain باHyperledger Fabric در Kubernetes (قسمت 4)

سایر مقالات در مورد ادغام Hyperledger Fabric با Spring Boot از لینک های زیر قابل دسترسی هستند.

بخش 1 – مقدمه

قسمت 2 – راه اندازی خوشه Kubernetes

قسمت 3 – Fabric CA Server

بخش 4- تولید گواهینامه ها و مصنوعات

قسمت پنجم – Kafka

قسمت 6 – سفارش دهنده

ابتدا اجازه دهید برخی از مفاهیمی که اغلب در مقاله تکرار می شوند را توضیح دهیم.

Anchor Peer

توسط شایعات استفاده می شود تا مطمئن شود همتایان در سازمان های مختلف از یکدیگر اطلاع دارند.

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

پیشنهاد ویژه: آموزش بلاکچین

ACL

یک ACL یا لیست کنترل دسترسی، دسترسی به منابع همتای خاص (مانند APIهای کد زنجیره‌ای سیستم یا سرویس‌های رویداد) را به یک خط‌مشی (که مشخص می‌کند چه تعداد و چه نوع سازمان‌ها یا نقش‌هایی مورد نیاز است) مرتبط می‌کند.

ACL بخشی از پیکربندی کانال است.

مجموعه ای از ACL های پیش فرض در فایل configtx.yaml ارائه شده است که توسط configtxgen برای ساخت پیکربندی کانال استفاده می شود.

(Block) مسدود کردن

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

از نظر رمزنگاری به بلوک قبلی مرتبط است و به نوبه خود به بلوک های بعدی پیوند داده می شود.

اولین بلوک در چنین زنجیره ای از بلوک ها بلوک پیدایش نامیده می شود.

بلوک‌ها توسط سرویس سفارش‌دهنده ایجاد می‌شوند و سپس توسط همتایان تأیید و متعهد می‌شوند.

کانال

کانال یک پوشش بلاک چین خصوصی است که امکان جداسازی و محرمانه بودن داده ها را فراهم می کند.

دفتر کل کانال در بین همتایان در کانال به اشتراک گذاشته می شود و طرفین تراکنش باید در یک کانال احراز هویت شوند تا بتوانند با آن تعامل داشته باشند.

تنظیمات پیکربندی

بیایید پروژه ای را که از این لینک دانلود کرده ایم باز کنیم و به دایرکتوری که k8s در آن قرار دارد برویم.

$ cd deploy/k8s

ما به فایل configtx.yaml برای ایجاد بلوک پیدایش و تراکنش کانال نیاز داریم. فایل yaml در deploy/k8s/fabricfiles/configtx/configtx.yaml است.

Organizations: Name: OrdererOrg # ID to load the MSP definition as ID: OrdererMSP # MSPDir is the filesystem path which contains the MSP configuration MSPDir: ../organizations/ordererOrganizations/example.com/msp ... OrdererEndpoints: - orderer:7050 - &Org1 # DefaultOrg defines the organization which is used in the sampleconfig # of the fabric.git development environment Name: Org1MSP # ID to load the MSP definition as ID: Org1MSP AnchorPeers: - Host: peer0-org1 Port: 7051 - &Org2 # DefaultOrg defines the organization which is used in the sampleconfig # of the fabric.git development environment Name: Org2MSP # ID to load the MSP definition as ID: Org2MSP MSPDir: ../organizations/peerOrganizations/org2.example.com/msp AnchorPeers: # AnchorPeers defines the location of peers which can be used # for cross org gossip communication. Note, this value is only # encoded in the genesis block in the Application section context - Host: peer0-org2 Port: 9051 - &Org3 # DefaultOrg defines the organization which is used in the sampleconfig # of the fabric.git development environment Name: Org3MSP # ID to load the MSP definition as ID: Org3MSP MSPDir: ../organizations/peerOrganizations/org3.example.com/msp AnchorPeers: # AnchorPeers defines the location of peers which can be used # for cross org gossip communication. Note, this value is only # encoded in the genesis block in the Application section context - Host: peer0-org3 Port: 11051 ... Orderer: &OrdererDefaults # Orderer Type: The orderer implementation to start OrdererType: kafka # Addresses used to be the list of orderer addresses that clients and peers # could connect to. However, this does not allow clients to associate orderer # addresses and orderer organizations which can be useful for things such # as TLS validation. The preferred way to specify orderer addresses is now # to include the OrdererEndpoints item in your org definition Addresses: - orderer:7050 - orderer2:7050 - orderer3:7050 - orderer4:7050 - orderer5:7050 ... Kafka: # Brokers: A list of Kafka brokers to which the orderer connects # NOTE: Use IP:port notation Brokers: - broker-0.broker:9092 - broker-1.broker:9092 ... Profiles: TwoOrgsOrdererGenesis: ... Organizations: - *Org1 - *Org2 - *Org3 TwoOrgsChannel: ... Organizations: - *Org1 - *Org2 - *Org3 ...

- &OrdererOrg # ID to load the MSP definition as ID: OrdererMSP

فیلد ID برای بارگیری تعاریف Orderer MSP مورد نیاز است. به همین ترتیب، این پارامتر در Org1، Org2 و Org3 اجباری است.

MSPDir: ../organizations/ordererOrganizations/example.com/msp

MSPDir مسیر فایل سیستمی است که شامل پیکربندی MSP است. این پارامتر در Org1، Org2 و Org3 اجباری است.

OrdererEndpoints: - orderer:7050

برای OrdererOrg، نام سرویس و اطلاعات پورت سرویس سفارش دهنده در kubernetes است.

AnchorPeers: # AnchorPeers defines the location of peers which can be used # for cross org gossip communication. Note, this value is only # encoded in the genesis block in the Application section context - Host: peer0-org1 Port: 7051

Anchor Peer مکان همتاهایی را که می‌توان استفاده کرد را مشخص می‌کند. باید برای هر سازمان تعریف شود. این نام سرویس و تعریف پورت سرویس همتا است که به عنوان لنگر همتا برای Org1 در kubernetes استفاده می‌شود. لنگر همتا باید در Org2 و Org3 تعریف شود.

Orderer: &OrdererDefaults # Orderer Type: The orderer implementation to start OrdererType: kafka

با این پیکربندی، گره های خدمات سفارش Hyperledger fabric (OSN) از خوشه کافکا شما استفاده می کنند و یک سرویس سفارش را به شبکه بلاک چین شما ارائه می دهند.

Addresses: - orderer:7050 - orderer2:7050 - orderer3:7050 - orderer4:7050 - orderer5:7050

نام سرویس و پورت سرویس سفارش دهندگان در kubernetes تعریف شده است. 5 سفارش دهنده در شبکه بلاک چین در حال اجرا هستند.نام سرویس و پورت سرویس سفارش دهندگان در kubernetes تعریف شده است. 5 سفارش دهنده در شبکه بلاک چین در حال اجرا هستند.

Kafka: # Brokers: A list of Kafka brokers to which the orderer connects # NOTE: Use IP:port notation Brokers: - broker-0.broker:9092 - broker-1.broker:9092

نام سرویس و پورت سرویس کارگزاران کافکا در kubernetes که سفارش دهنده به آن متصل خواهد شد، تعریف شده است. ما در این پروژه خوشه کافکا را راه اندازی خواهیم کرد. کافکا 2 نمونه اجرا خواهد کرد.

TwoOrgsOrdererGenesis: ... Organizations: - *Org1 - *Org2 - *Org3

نمایه TwoOrgsOrdererGenesis باید برای ایجاد یک بلوک پیدایش تعریف شود. 3 سازمان در این پیکربندی تعریف شده اند.

TwoOrgsChannel: ... Organizations: - *Org1 - *Org2 - *Org3

نمایه TwoOrgsChannel باید برای ایجاد تراکنش کانال تعریف شود. 3 سازمان در این پیکربندی تعریف شده اند.

تولید اسکریپت های گواهی تعریف شده در پروژه برای سفارش دهنده به شرح زیر است. فایل اسکریپت در deploy/k8s/fabricfiles/scripts/orderer-certs.sh است.

sleep 2 mkdir -p organizations/ordererOrganizations/example.com export FABRIC_CA_CLIENT_HOME=/organizations/ordererOrganizations/example.com echo $FABRIC_CA_CLIENT_HOME set -x fabric-ca-client enroll -u https://admin:adminpw@ca-orderer:10054 --caname ca-orderer --tls.certfiles /organizations/fabric-ca/ordererOrg/tls-cert.pem { set +x; } 2>/dev/null ... echo "Register orderer" ... echo "Register orderer2" ... echo "Register orderer3" ... echo "Register orderer4" ... echo "Register orderer5" ... echo "Register the orderer admin" ... echo "Generate the orderer-tls certificates" ... echo "Generate the orderer5 msp" ... echo "Generate the orderer5-tls certificates" ... echo "Generate the admin msp"

.Certificate Authorities برای تولید هویت های اختصاص داده شده به ادمین ها، گره ها و کاربران (برنامه های مشتری) استفاده می شود. این اسکریپت گواهی tls، msp را برای هر یک از سفارش دهندگان ایجاد می کند و شناسه ها را در CA ثبت و ثبت می کند.

اسکریپت های تولید گواهی تعریف شده در پروژه برای Org1، Org2 و Org3 به شرح زیر است. فایل های اسکریپت در پوشه deploy/k8s/fabricfiles/scripts قرار دارند.

set -x mkdir -p /organizations/peerOrganizations/org1.example.com/ export FABRIC_CA_CLIENT_HOME=/organizations/peerOrganizations/org1.example.com/ fabric-ca-client enroll -u https://admin:adminpw@ca-org1:7054 --caname ca-org1 --tls.certfiles "/organizations/fabric-ca/org1/tls-cert.pem" ... fabric-ca-client register --caname ca-org1 --id.name peer0 --id.secret peer0pw --id.type peer --tls.certfiles "/organizations/fabric-ca/org1/tls-cert.pem" fabric-ca-client register --caname ca-org1 --id.name user1 --id.secret user1pw --id.type client --tls.certfiles "/organizations/fabric-ca/org1/tls-cert.pem" fabric-ca-client register --caname ca-org1 --id.name org1admin --id.secret org1adminpw --id.type admin --tls.certfiles "/organizations/fabric-ca/org1/tls-cert.pem" ... cp "/organizations/peerOrganizations/org1.example.com/msp/config.yaml" "/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/config.yaml" { set +x; } 2>/dev/null

set -x mkdir -p /organizations/peerOrganizations/org2.example.com/ export FABRIC_CA_CLIENT_HOME=/organizations/peerOrganizations/org2.example.com/ fabric-ca-client enroll -u https://admin:adminpw@ca-org2:8054 --caname ca-org2 --tls.certfiles "/organizations/fabric-ca/org2/tls-cert.pem" ... fabric-ca-client register --caname ca-org2 --id.name peer0 --id.secret peer0pw --id.type peer --tls.certfiles "/organizations/fabric-ca/org2/tls-cert.pem" fabric-ca-client register --caname ca-org2 --id.name user1 --id.secret user1pw --id.type client --tls.certfiles "/organizations/fabric-ca/org2/tls-cert.pem" fabric-ca-client register --caname ca-org2 --id.name org2admin --id.secret org2adminpw --id.type admin --tls.certfiles "/organizations/fabric-ca/org2/tls-cert.pem" ... cp "/organizations/peerOrganizations/org2.example.com/msp/config.yaml" "/organizations/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp/config.yaml" { set +x; } 2>/dev/null

set -x mkdir -p /organizations/peerOrganizations/org3.example.com/ export FABRIC_CA_CLIENT_HOME=/organizations/peerOrganizations/org3.example.com/ fabric-ca-client enroll -u https://admin:adminpw@ca-org3:9054 --caname ca-org3 --tls.certfiles "/organizations/fabric-ca/org3/tls-cert.pem" fabric-ca-client register --caname ca-org3 --id.name peer0 --id.secret peer0pw --id.type peer --tls.certfiles "/organizations/fabric-ca/org3/tls-cert.pem" fabric-ca-client register --caname ca-org3 --id.name user1 --id.secret user1pw --id.type client --tls.certfiles "/organizations/fabric-ca/org3/tls-cert.pem" fabric-ca-client register --caname ca-org3 --id.name org3admin --id.secret org3adminpw --id.type admin --tls.certfiles "/organizations/fabric-ca/org3/tls-cert.pem" ... cp "/organizations/peerOrganizations/org3.example.com/msp/config.yaml" "/organizations/peerOrganizations/org3.example.com/users/Admin@org3.example.com/msp/config.yaml" { set +x; } 2>/dev/null

این اسکریپت ها گواهی tls، msp را برای هر یک از سازمان ها ایجاد می کنند و شناسه ها را با CA ثبت و ثبت می کنند.

اسکریپت های تولید کننده مصنوع تعریف شده در پروژه به شرح زیر است. فایل های اسکریپت در پوشه deploy/k8s/fabricfiles/scripts قرار دارند.

CHANNEL_NAME="$1" DELAY="$2" MAX_RETRY="$3" VERBOSE="$4" : ${CHANNEL_NAME:="mychannel"} : ${DELAY:="3"} : ${MAX_RETRY:="5"} : ${VERBOSE:="true"} FABRIC_CFG_PATH=${PWD}configtx createChannelTx() { set -x configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./channel-artifacts/${CHANNEL_NAME}.tx -channelID $CHANNEL_NAME ... } createAncorPeerTx() { for orgmsp in Org1MSP Org2MSP Org3MSP; do echo "Generating anchor peer update transaction for ${orgmsp}" set -x configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/${orgmsp}anchors.tx -channelID $CHANNEL_NAME -asOrg ${orgmsp} ... done } ## Create channeltx echo "Generating channel create transaction '${CHANNEL_NAME}.tx'" createChannelTx ## Create anchorpeertx echo "Generating anchor peer update transactions" createAncorPeerTx exit 0

export FABRIC_CFG_PATH=${PWD}configtx configtxgen -profile TwoOrgsOrdererGenesis -channelID system-channel -outputBlock ./system-genesis-block/genesis.block

configtxgen -profile TwoOrgsOrdererGenesis

نمایه TwoOrgsOrdererGenesis باید در فایل configtx.yaml تعریف شود. برای ایجاد بلوک Genesis لازم است.

-channelID system-channel

برای ایجاد بلوک Genesis شناسه کانال باید سیستم-کانال باشد.

configtxgen -profile TwoOrgsChannel

نمایه TwoOrgsChannel باید در فایل configtx.yaml تعریف شود. برای ایجاد تراکنش کانال لازم است.

CHANNEL_NAME:="mychannel"

کانال یک “زیر شبکه” خصوصی از ارتباط بین دو یا چند عضو خاص شبکه است، به منظور انجام تراکنش های خصوصی و محرمانه. اطلاعات شناسه کانال برای ایجاد تراکنش کانال مورد نیاز است. شناسه کانال به “mychannel” اختصاص داده می شود.

for orgmsp in Org1MSP Org2MSP Org3MSP; do set -x configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/${orgmsp}anchors.tx -channelID $CHANNEL_NAME -asOrg ${orgmsp} done

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

اجازه دهید یک کار ایجاد گواهی ایجاد کنیم، create-certs.yaml. فایل yaml در پوشه deploy/k8s/job است.

apiVersion: batch/v1 kind: Job metadata: name: create-certs spec: backoffLimit: 1 parallelism: 1 completions: 1 template: metadata: name: create-certs spec: containers: - name: create-certs image: hyperledger/fabric-ca-tools:1.2.1 command: - /bin/sh - -c - | ./scripts/orderer-certs.sh && ./scripts/org1-certs.sh && ./scripts/org2-certs.sh && ./scripts/org3-certs.sh ... volumeMounts: - name: fabricfiles mountPath: /organizations subPath: organizations - name: fabricfiles mountPath: /scripts subPath: scripts restartPolicy: Never volumes: - name: fabricfiles persistentVolumeClaim: claimName: fabricfiles-pvc

- | ./scripts/orderer-certs.sh && ./scripts/org1-certs.sh && ./scripts/org2-certs.sh && ./scripts/org3-certs.sh

اسکریپت هایی برای اجرا در کار برای ایجاد گواهی ها تعریف می شوند.

volumeMounts: - name: fabricfiles mountPath: /organizations subPath: organizations - name: fabricfiles mountPath: /scripts subPath: scripts

برای دسترسی به پوشه اسکریپت ها و پوشه سازمان ها در سرور nfs مورد نیاز است. گواهی ها در پوشه سازمان ها ایجاد می شوند.

volumes: - name: fabricfiles persistentVolumeClaim: claimName: fabricfiles-pvc

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

apiVersion: batch/v1 kind: Job metadata: name: create-artifacts spec: backoffLimit: 1 template: spec: containers: - name: create-artifacts image: hyperledger/fabric-tools:2.3 workingDir: / command: - /bin/bash - -c - | ./scripts/createGenesis.sh && ./scripts/createChannel.sh volumeMounts: - name: fabricfiles mountPath: /organizations subPath: organizations - name: fabricfiles mountPath: /configtx subPath: configtx - name: fabricfiles mountPath: /system-genesis-block subPath: system-genesis-block - name: fabricfiles mountPath: /channel-artifacts subPath: channel-artifacts - name: fabricfiles mountPath: /scripts subPath: scripts restartPolicy: Never volumes: - name: fabricfiles persistentVolumeClaim: claimName: fabricfiles-pvc

به ما این امکان را می دهد که فایل های فابریک را روی سرور nfs روی کانتینر سوار کنیم.

- | ./scripts/createGenesis.sh && ./scripts/createChannel.sh

اسکریپت هایی برای اجرا در کار برای ایجاد مصنوعات تعریف می شوند.

volumeMounts: - name: fabricfiles mountPath: /organizations subPath: organizations - name: fabricfiles mountPath: /configtx subPath: configtx - name: fabricfiles mountPath: /system-genesis-block subPath: system-genesis-block - name: fabricfiles mountPath: /channel-artifacts subPath: channel-artifacts - name: fabricfiles mountPath: /scripts subPath: scripts

برای دسترسی به پوشه اسکریپت ها، پوشه configtx و پوشه سازمان ها در سرور nfs مورد نیاز است. بلوک جنسیس سیستم در پوشه system-genesis-block ایجاد می شود. آرتیفکت های کانال در پوشه channel-artifacts ایجاد می شوند.

نصب Jobs در Kubernetes

بیایید با دستور Vagrant ssh به ماشین مجازی kubernetes master node متصل شویم.

$ vagrant ssh k8smaster

بیایید به دایرکتوری برویم که اسکریپت های نصب kubernetes در آن قرار دارند. این دایرکتوری همان پوشه deploy/k8s در پروژه است. با Vagrant، این دایرکتوری با ماشین مجازی همگام سازی می شود.

$ cd /vagrant/k8s

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

$ kubectl apply -f job/create-certs.yaml

شغل ایجاد گواهی در انتظار تکمیل

$ kubectl wait --for=condition=complete --timeout=300s job create-certs

پس از اتمام کار، ordererOrganizations و peerOrganizations در زیر پوشه Organizations در سرور nfs ایجاد شدند. اجازه دهید بررسی کنیم که آیا این پوشه ها ایجاد شده اند یا خیر.

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

$ vagrant ssh nfsserver

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

$ ls /srv/kubedata/fabricfiles/organizations

همانطور که می بینید، پوشه های ordererOrganizations و peerOrganizations ایجاد شده اند. ایجاد گواهی با موفقیت انجام شد.

بیایید به ترمینال گره اصلی kubernetes برگردیم.

استقرار کار مصنوعات گواهی.

$ kubectl apply -f job/create-artifacts.yaml

کار ایجاد مصنوعات در انتظار تکمیل.

$ kubectl wait --for=condition=complete --timeout=300s job create-artifacts

پس از اتمام کار، system-genesis-block و channel-artifacts در زیر پوشه fabricfiles در سرور nfs ایجاد شدند. اجازه دهید بررسی کنیم که آیا این پوشه ها ایجاد شده اند یا خیر.

بیایید به ترمینال ماشین مجازی سرور nfs برگردیم.

بیایید پوشه های زیر پوشه فابریک فایل ها را فهرست کنیم.

$ ls /srv/kubedata/fabricfiles

همانطور که می بینید، پوشه های system-genesis-block و channel-artifacts ایجاد شده اند. ایجاد Artifacts با موفقیت انجام شد.

در نهایت، بیایید شرایط کارهایی را که از ایده لنز اجرا می کنیم، بررسی کنیم.

کارهایی که ما انجام می دهیم تکمیل شده است.

به طور کلی، تولید گواهی برای همتایان، سفارش دهنده و ایجاد بلوک پیدایش و ایجاد تراکنش های کانال در Kubernetes توضیح داده شد.

در این مقاله به Hyperledger Caliper که ابزاری برای اندازه گیری عملکرد بلاک چین مب باشد می پردازیم.

فناوری بلاک چین روز به روز توجه بیشتری را به خود جلب می کند، اما هیچ راهی وجود ندارد که بتوانید عملکرد پلتفرم های مختلف بلاک چین را قبل از ایجاد راه حل برای مشکل کسب و کار خود آزمایش کنید. برای در نظر گرفتن این موضوع، جامعه Hyperledger ابزاری به نام Hyperledger Caliper ارائه کرده است که می تواند برای اندازه گیری عملکرد بلاک چین استفاده شود.

Hyperledger Caliper چیست؟

Caliper یک چارچوب معیار عملکرد بلاک چین است که به کاربران اجازه می دهد راه حل های مختلف بلاک چین را با موارد استفاده از پیش تعریف شده آزمایش کنند و مجموعه ای از نتایج تست عملکرد را دریافت کنند.

شاخص های عملکرد پشتیبانی شده 

میزان موفقیت
تراکنش/خواندن ورودی
تاخیر تراکنش/خواندن (حداقل، حداکثر، متوسط، صدک)
مصرف منابع (CPU، حافظه، IO شبکه،…..)

معماری

Adaptation Layer

Adaptation Layer برای ادغام سیستم بلاک چین موجود در چارچوب Caliper استفاده می‌شود. هر آداپتور NBI Blockchain Caliper را با استفاده از SDK بومی بلاک چین یا RESTful API پیاده‌سازی می‌کند.

Interface و Core Layer

لایه Interface & Core توابع اصلی را پیاده سازی می کند و رابط های محدود شمال را برای برنامه های کاربردی بالا فراهم می کند. چهار نوع NBI ارائه شده است:

• Blockchain operating interfaces ( رابط های عملیاتی بلاک چین): شامل عملیات هایی مانند استقرار قراردادهای هوشمند در بلاک چین باطن، فراخوانی قراردادها، درخواست وضعیت ها از دفتر کل و غیره است.

•  Resource Monitor ( مانیتور منابع): شامل عملیاتی برای راه‌اندازی/توقف یک مانیتور و واکشی وضعیت مصرف منابع سیستم بلاک‌چین پشتیبان، از جمله CPU، حافظه، IO شبکه و غیره است. دو نوع مانیتور در حال حاضر ارائه شده است، یکی تماشای کانتینر محلی/ریموت docker و دیگری تماشای فرآیندهای محلی است.

• Performance Analyzer (تجزیه و تحلیل عملکرد): شامل عملیات برای خواندن آمار عملکرد از پیش تعریف شده (شامل TPS، تاخیر، نسبت موفقیت و غیره) و چاپ نتایج معیار است. معیارهای کلیدی هنگام فراخوانی NBI های بلاک چین ثبت می شوند، به عنوان مثال. زمان ایجاد شده و زمان تعهد معامله، نتیجه معامله و غیره

•  Report Generator: شامل عملیاتی برای تولید گزارش تست فرمت HTML است

Application Layer

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

یک موتور بنچمارک پیش‌فرض برای کمک به توسعه‌دهندگان برای درک چارچوب و اجرای سریع تست خود پیاده‌سازی شده است. توسعه دهندگان می توانند مستقیماً از NBI برای اجرای آزمایش خود بدون چارچوب استفاده کنند.

Benchmark Engine