besu-eth

Besuで許可型EVMを手元に立てて、社債セキュリティトークンの移転制限を書いてみた こんにちは！ブロックチェーン×AI Agentで自律経済圏を創るKomlock lab（Pacific Meta Group）でエンジニアをしている小原（@brto_0224）です。 参加者を限定したBesuネットワークなら、トークンの移転先も制限できるのでしょうか。今回は手元に4台のバリデータを立て、許可リストにいない投資家への移転が拒否され、登録後は成功するところまで確かめました。 BesuはEthereumのクライアントで、公開ネットワークにも、参加者を限定した企業向けネットワークにも使えます。金融分野では証券や決済の基盤にも使われていて、DTCCはTokenization Serviceの基盤の一つとして、自社のプライベートBesuネットワークを使っています。このサービスは2026年10月28日に本番稼働しました。 dtcc.com 今回は、その企業向けネットワークを手元に立てて、社債セキュリティトークンの移転制限を書いてみます。 今回の実行環境は次のとおりです。 Debian 13（trixie）、x86_64、8コア、RAM 16GB Docker 26.1.5（aptのdocker.io）、Docker Compose 2.26.1 Node v22.23.2、npm 10.9.8 @consensys-software/besu-dev-quickstart 0.2.2 Besu 26.2.0（besu/v26.2.0/linux-x86_64/openjdk-java-25、Java 25） Foundry（forge）1.8.7、solc 0.8.30 今回はクイックスタートが指定する26.2.0を使用しました。 Besuはパブリックにも許可型にもなるEVM BesuはJavaで書かれたEthereumクライアントです。今回使うQBFTでは、許可されたバリデータだけがブロックを作ります。さらに、各ノードの設定ファイルに許可するノードやアカウントの一覧を書いておくと、ネットワークに参加できるノードや、トランザクションを送れるアカウントを絞り込めます。Besuではこの仕組みをローカルpermissioningと呼びます。 ! QBFTはBesuで使える合意アルゴリズムの1つで、参加者を限定したネットワーク向けです。あらかじめ決めたバリデータが投票し、3分の2以上の合意でブロックを確定します。今回の4台構成では3台の承認でブロックが確定し、1台の故障までは耐えられますが、3分の1を超えるバリデータが止まるとブロック生成は止まります。確定したブロックは後から覆らず、公開EthereumのPoSとは違い、誰でもバリデータになれるわけではありません。 docs.besu-eth.org docs.besu-eth.org セキュリティトークン（ST）は、普通のトークンと違って、本人確認を終えた投資家のあいだでしか発行や移転ができないといったルールを守る必要があります。Besu のように参加者を限ったネットワークを使えばこのルールも守れそうに見えますが、ネットワーク側で制御できるのはノードへの接続やトランザクションの受け付けまでです。発行や移転のときに誰が送り手・受け手になれるかは、コントラクトが残高を動かすときに判定するので、この二つは分けて設計する必要があります。 手元で同じ手順を再現したい場合は、サンプルリポジトリを使えます。この記事の内容はタグ v1.1.0 で検証しました。記事では仕組みと結果を中心に書き、細かい手順は README に任せます。 github.com/br-to/besu-bond-hands-on/tree/v1.1.0 再現するには Foundry（forge / cast）を入れ、リポジトリを clone して .env.example を .env にコピーします。発行体は公式 Test Account 1、投資家Aは Test Account 2、投資家Bは Test Account 3 です。TOKEN には記事中のアドレスではなく、自分のデプロイ結果を入れてください。新しいネットワークで同じアカウントから最初にデプロイすれば同じアドレスになる場合もありますが、必ず自分の出力を使います。 book.getfoundry.sh ハンズオン1: 公式クイックスタートで4バリデータを立てる 次の図は、手元のPCからDocker上のBesuネットワークへ操作を送るときに通る、2つの関門です。 ①はどのノードがネットワークに入れるかという参加の許可、②は誰がトークンを受け取り・送れるかという移転の許可で、別の層にあります。 公式Dockerクイックスタートで、承認役（バリデータ）4台と操作を受け付けるノード1台のネットワークを立てます。前提はDocker、Compose v2以上、Node.js、curlです。ドキュメントではDockerへ最大6GBのメモリを割り当てるよう案内されています。 docs.besu-eth.org 今回の環境ではユーザーがdockerグループに入っていなかったため、run.shにsudoを付けています。 npx -y @consensys-software/besu-dev-quickstart@0.2.2 --networkType private \ --outputPath ./besu-test-network --otel false --chainlens true cd besu-test-network && sudo ./run.sh 起動後はブロック番号を見ればよく、番号が増えていればチェーンは動いています。 curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \ 127.0.0.1 -H "Content-Type: application/json" run.sh のあとは besu-test-network にいるので、コントラクト操作の前にリポジトリ直下へ戻ります。環境によってブロックが進まない場合の対処は、リポジトリのREADMEにまとめています。 ハンズオン2: allowlist型の社債セキュリティトークンを書く 次の図は、許可リストと残高を並べながら、移転制限ハンズオンの5ステップを追ったものです。 ③で失敗した移転は、④でBを許可したあとの⑤で通り、残高はAが90、Bが10になります。 次に、社債を額面単位で表す最小のコントラクトAllowlistBondを作りました。発行体だけがsetAllowedでアドレスの許可状態を変えられ、issueは受け手が、transferは送り手と受け手がallowlistにいるかを確認します。許可を取り消しても残高は残るため、取り消したあとは新規の発行や移転ができなくなるだけで、すでに持っている分が消えるわけではありません。コントラクト全体はリポジトリで見られます。 function setAllowed(address account, bool allowed) external onlyIssuer { isAllowed[account] = allowed; emit AllowlistUpdated(account, allowed); } function issue(address to, uint256 units) external onlyIssuer { if (!isAllowed[to]) revert NotAllowed(to); // ... } function transfer(address to, uint256 units) external returns (bool) { if (!isAllowed[msg.sender]) revert NotAllowed(msg.sender); if (!isAllowed[to]) revert NotAllowed(to); // ... } ! ERC-3643（T-REX）は、セキュリティトークン向けに、ERC-20へ本人確認情報の登録と移転ルールの判定を組み合わせた規格です。投資家の身元は本人確認レジストリ（Identity Registry）が管理し、保有者数の上限や国ごとの制限といった移転ルールはコンプライアンスモジュールが判定します。 これは学習用のERC-20風実装で、ERC-3643/T-REXではなく、本人確認レジストリやコンプライアンスモジュールも持ちません。faceValuePerUnitとmaturityは値を保存しているだけで、利払い、償還、満期後の処理は実装していません。実際の社債を表す本番用コントラクトではありません。 クイックスタートの genesis が Cancun までの設定のため、最新のアップグレードではなくチェーン側に合わせて cancun を指定しています。 [profile.default] src = "src" out = "out" solc_version = "0.8.30" evm_version = "cancun" リポジトリ直下へ戻り、.env を読み込んでからデプロイします。ここには秘密鍵の値を掲載しません。--legacy は付けず、Foundryの既定のまま実行しました。TOKEN は出力の Deployed to: を、自分のデプロイ結果に置き換えてください。 cd .. cp .env.example .env set -a && source .env && set +a forge create src/AllowlistBond.sol:AllowlistBond \ --rpc-url "$RPC_URL" --private-key "$ISSUER_KEY" \ --broadcast --constructor-args 1000000 1830297600 0x...を「Deployed to:」に表示されたアドレスへ置き換える export TOKEN="0x..." 今回の通し実行では Deployed to: 0x42699A7612A82f1d9C36148af9C77354759b210b でした。 つづいて発行体が投資家Aを許可し、100単位を発行します。 cast send "$TOKEN" "setAllowed(address,bool)" "$A" true \ --rpc-url "$RPC_URL" --private-key "$ISSUER_KEY" cast send "$TOKEN" "issue(address,uint256)" "$A" 100 \ --rpc-url "$RPC_URL" --private-key "$ISSUER_KEY" どちらも成功し、Aの残高は100になります。 まだ許可していないBへ、Aから10単位を送ります。 cast send "$TOKEN" "transfer(address,uint256)" "$B" 10 \ --rpc-url "$RPC_URL" --private-key "$A_KEY" cast send は送信前のgas見積もりで NotAllowed を返し、トランザクションは送られません。 Bを許可したあと、同じ移転をもう一度実行します。 cast send "$TOKEN" "setAllowed(address,bool)" "$B" true \ --rpc-url "$RPC_URL" --private-key "$ISSUER_KEY" cast send "$TOKEN" "transfer(address,uint256)" "$B" 10 \ --rpc-url "$RPC_URL" --private-key "$A_KEY" cast call "$TOKEN" "balanceOf(address)(uint256)" "$A" --rpc-url "$RPC_URL" cast call "$TOKEN" "balanceOf(address)(uint256)" "$B" --rpc-url "$RPC_URL" 同じ移転が通り、残高はAが90、Bが10でした。 ノード層の許可は何を制御するのか Besuの公式ドキュメントによると、アカウントのallowlistは、そのノードへのeth_sendRawTransaction、他ノードから伝播したトランザクション、そのノードがブロックを作る場面で働きます。一方、他ノードが作ったブロックを検証するときには、このallowlistを適用しません。そのため、全ノードで同じallowlistを使うことが推奨されています。 docs.besu-eth.org 今回のクイックスタートでは、permissions-nodes-config-file-enabled=trueによるノードのallowlistだけが有効です。アカウントのallowlistは有効にしておらず、その挙動は試していません。 ノード層の許可はネットワークの参加やトランザクション受け付けに関わりますが、発行や移転のときに誰が送り手・受け手になれるかは、資産のルールとしてコントラクトへ書く必要があります。 許可型Besuとパブリックチェーン上の許可型トークン STを動かす設計は許可型Besuだけではなく、パブリックチェーンへ許可リスト型トークンを載せ、発行や移転のときに送り手と受け手が許可されているかをコントラクトで確認する設計も考えられます。 観点 許可型Besu パブリックチェーン＋許可リスト型トークン バリデータ 運営者が許可した参加者 パブリックチェーンのバリデータ トークンの発行・移転の条件 コントラクトで判定 コントラクトで判定 ノードへの入口 ローカルpermissioningで制御できる 原則として公開 データの見え方 許可型でも参加ノードには共有される パブリックに共有される コントラクト Solidityで実装 Solidityで実装できるEVMなら同じ開発資産を使いやすい Besuの公式ドキュメントでは、QBFTとIBFT 2.0は即時ファイナリティを持ち、フォークが起きないと説明されています。 docs.besu-eth.org Besuのプライバシー機能は本体からアプリ側へ 許可型ネットワークでも、参加ノードには取引の中身が見えます。プライバシーはBesu 25.6.0で本体のTesseraから外れ、Paladinのようなアプリ側の仕組みを載せる形になりました。 ! PaladinはLinux Foundation Decentralized Trustのプロジェクトで、標準のEVMチェーンの上でプライベートなトークンやスマートコントラクトを扱う仕組みです。Besuノードと並べて動かし、Penteのプライバシーグループ、公証人付きトークンのNoto、ゼロ知識証明のZetoといった方式を使えます。 lfdt-paladin.github.io github.com/besu-eth/besu/releases/tag/25.6.0 まとめ: 許可型EVMでも資産のルールはコントラクトに残る Besuのpermissioningだけでは、社債STの移転制限にはなりません。ノード層はネットワークの入口を管理し、コントラクト層は発行や移転の送り手と受け手を管理します。この境界を分けておくと、インフラ運営者の権限と発行体のコンプライアンス判断を別々に扱えます。 今回の単純な許可リストとは違い、ERC-3643は移転時に受取人の資格だけでなく、凍結状態や残高、移転ルールまで確認します。本番の社債セキュリティトークンでは、こうした仕組みを前提に設計することになります。 eips.ethereum.org

@eMudhra Quelle: coindesk.com Quelle: hackmd.io Quelle: github.com/besu-eth/besu/wiki/Incident-Report-202… Folgt uns für mehr Insights 🔔

ATTENTION all Besu users: please check if you are impacted by the eMudhra CA certificates incident and follow the guidance: github.com/besu-eth/besu/wiki/Incident-Report-202…

ATTENTION all Besu users: please check if you are impacted by the eMudhra CA certificates incident and follow the guidance: github.com/besu-eth/besu/wiki/Incident-Report-202…

If you operate nodes on Hoodi, upgrade to 26.10.1 immediately. The Hoodi upgrade to Glamsterdam has been postponed. This release is identical to 26.10.0 but will not activate Glamsterdam on Hoodi networks. github.com/besu-eth/besu/releases/tag/26.10.1

Amsterdam's next stop: Hoodi, on Oct 26. @Besu_eth 26.10.0 is out with the fork scheduled. Hoodi operators, upgrade before then ↓ github.com/besu-eth/besu/releases/tag/26.10.0