あ
ETHの価格が今後上がるにはどうすれば良いのかを考えてみる。 (ここで言う「上がる」とは、同じような環境で売買が行われているBTCの値動きをアウトパフォームすることを指す。長期的にこれをアウトパフォームする見込みがないのであればそもそも保有する意義はなく、他の養分よりも先に抜けた方が良い。) PoSを放棄する Posへの移行は様々な思惑があった上での決断だったと思われる。例えばスケーリングを行っていく上で必須だったとか、ビットコインと差別化するためとか、環境対策(笑)のためとか、PoWがエネルギーの無駄遣いだと思っていた運営者が「そんな面倒なことせんでもクリプトには価値がつくことを証明したるで！」的な気概を持っていたとか、まぁこんなところだろう。 PoS移行から2年経過した今、結果は出つつある。価格という面では完全に失敗している。 PoSを放棄したETHに価値がつくためには、十分な配当利回りがなければならない。2年前に放棄して以降、新規にコインを生産するコストが相対的にゼロになっており、単なるイージーマネーになっているためだ。また内部留保が存在しないため解散価値はなく、価格がつく根拠は本当に配当利回りにしかない。そしてその利回りも落ち続けており、今では3%を切っている。今後更にスケーリングが発達してガス使用量が下がることを考えると、利回りが上がる見込みもない。価格が下がるのも当然なのだ。 こんな話をすると、必ずと言っていいほど信者の方々から以下のようなお叱りの言葉を頂く。「ETHもSoVだ！V神も言ってた！」と。なるほど、彼も養分を引き止めるために必死なようだ。 ゴールドのようなSoVを持ち合わせるアセットとなるためには、生産するためにコストが掛かることは必須条件である。その上でハードマネー間で競争しなければならない。 生産コストが掛からないということは、すなわちコピーが容易であることを意味する。事実、イーサリアムのコピーは大量に作られ続けている。スマートコントラクト上でカジノに興じたいという限られた需要を奪われ続けている形だ。そのうちのいくつかはイーサリアムを脅かす存在にまで成長している。 ここでもまた一つ、お叱りが来そうだ。その内容は簡単に想像できるので読者自身で考えてみてほしい。これに回答しよう。そもそもスマートコントラクトをいくら分散化させたところで、その上にはチェーンの"外"にあるアセットを載せることしかできない。それは米国債だったり銀行口座残高だったり、不動産だったりする。これらは必ずチェーンの外に存在する。外に存在する以上、外の世界とチェーンとを橋渡しする主体が必要なのだ。これが単一障害点になる。USDTやUSDCの管理者が任意のアドレスにあるステーブルコインを凍結する権限を持っていることは皆さんも御存知だろう。橋渡しとはそういうことなのだ。既存のスマートコントラクトは全てチェーンの外にある価値を流通させることしかできない。つまり、単一障害点の存在なしには成り立たないのだ。これはUSDTやUSDCが一切流
Greenlightをセルフホストしてリモート署名をする⚡
GreenlightはBlockstream社が開発しているLNノードとその秘密鍵を分離して、リモート署名を可能にするサービスです。言い換えると、秘密鍵は自己管理して、LNノードをマネージドサービスとして利用することができます。LNノードと秘密鍵を分離することのメリットは以下が上げられます。 ノードの保守管理が不要となる 秘密鍵を自己管理できる（ハッキングによる資金流出リスクを低減） ウォレット開発コストが低減する Lappsの連携が容易になる 既存のモバイル用LNウォレットはLNノード自体が搭載されているものや、LDKのようなライブラリを組み合わせてLNノードをモバイル向けに実装するものが主流ですが、これはウォレットのパフォーマンスが低下したり、開発コストが高くなります。これはペイメントチャネル特有の状態管理やオニオンルーティングの経路選択など様々な処理をしなければならないからです。一方、オンチェーン専用のビットコインウォレットやメタマスク等はこの状態管理は不要で、主に送金時の署名をするだけでよいので、LNウォレットと比べると開発コストはそこまで高くありません。 Greenlightでは、ノード（ペイメントチャネルの状態管理）と秘密鍵（署名）を分離することで、開発者は署名に関する箇所だけを実装すればよく、LNノード自体を気にする必要がありません。また、ユーザーとしても秘密鍵のみ管理すればよく、LNノードの保守管理は不要になります。 基本的に秘密鍵さえ管理していれば、あとはマネージドサービスを利用するだけで、LNノードでの送受信ができますが、今回はGreenlightをマネージドからセルフホストする方法について試したことを以下に記載します。 --- １．セットアップ Greenlightのレポジトリからソースコードをクローンして、ビルドします。ビルドにはDockerが必要です。詳細はこちらのチュートリアルを参照ください。 $ git clone git@github.com:Blockstream/greenlight.git gl-testing-tutorial $ cd gl-testing-tutorial $ make docker-image $ make build-self 一度、チュートリアルのサ
L2のデザインパターン
Bitcoinコントリビュータとしてビットコイン開発を推進してきたうちの1人であるPeter Todd氏による現状のL2概要についての記事が素晴らしかったので、簡単に紹介します。 https://petertodd.org/2024/covenant-dependent-layer-2-review --- L2のデザインパターンには大きく分けて２種類ある
Greenlightとチャネルの強制閉鎖
Greenlight, BreezSDKを使ったライトニング搭載ビットコインウォレットを開発中に、テスターから強制チャネル閉鎖になると報告がいくつかありました。そこでテスターからログをいただき、解析してみた結果、ビットコイン、ライトニング特有な原因であることがわかりました。以下はそのログの原因箇所を抜粋したものです。 19:08:57 : DEBUG 02c...70d-channeld-chan#1: Received commit_sig with 0 htlc sigs 19:08:59 : DEBUG 02c...70d-channeld-chan#1: sending_revoke_and_ack: HTLC REMOTE 15 = SENT_ADD_REVOCATION/RCVD_ADD_REVOCATION 19:08:59 : DEBUG 02c...70d-channeld-chan#1: revoke_and_ack made pending: commit timer 19:08:59 : DEBUG 02c...70d-channeld-chan#1: Sending master 1021 19:08:59 : UNUSUAL 02c...70d-chan#1: Deferring incoming commit until we sync ライトニングの送金は、送信者と受信者が互いにその取引に署名をします。まずは、送信者がコミットメントに対して署名をします。受信者はそれを受け取り、内容に問題がなければ、古いコミットメントを失効させます。この際、受信者は古いコミットメントがオンチェーンへブロードキャストされていないか確認する必要があります。そのためには、まずはビットコインの最新のブロック高まで同期して確認します。もしブロック高の同期が未完であれば、相手からのコミットメントを受け取ってもその処理を中断して、ブロック高の同期を待ちます。もし、この状態でアプリを閉じてしまうとどうなるか...送信者はコミットメントに署名をして受信者へ渡した状態で、これは送金が宙に浮いている状態です。この場合ライトニングでは、ある一定期間が経過すると、その中途半端な取引をオンチェーンへ展開して資金を回収するプロトコルになっています。これが所謂、チャネルの強制閉鎖です。 ウォレットを開き、支払いを受け取ろうとする。しかしブロック高の同期が完了していない場合、その取引は中途半端になる。その状態でアプリを閉じることで、一定期間経過後にチャネルが閉鎖されてしまう。これがテスターから報告のあったチャネル強制閉鎖の原因でした。 対応策は、ブロック同期が完了するまでインボイスの生成や受け取りができないようにすれば良いはずです。 GreenlightやBreezSDKといったライトニングウォレットの開発が楽になるツールがでてきても、ブロック高の同期など、ビットコインの基本的な処理が必須で、これが「
なぜCLNの送金は不安定なのか
LNDの経路探索（pathfinding）の肝はMission Controlである。これによりLNDの送金は比較的安定しており、個人的にも満足している。Mission Controlには主に2つの探索手法がある。 Apriori estimator：これは過去の送金データを元に成功確率の高い経路を探索する。未試行なホップの成功率を60%として、これをアプリオリな値としている Bimodal estimator：大半のチャネルは流量性が偏っているという前提で、成功率はチャネルサイズに比例（大きなチャネルほど成功率が高い）する 一方、CLNの送金は不安定であり、送金時間も比較的長いという感覚がある。なぜCLNの送金は不安定なのか。CLNはチャネルサイズを元に経路を探索する（LNDでいうBimodal estimator）。それに加えて、経路のランダム化や金額を小さく分割して送金するMPPなどを活用して、プライバシー重視な経路探索をする。 CLNがLNDと比べて送金が不安定な要因は、過去の送金データを保存していなことである。過去に送金が失敗した経路を区別することができないため、再度同じ経路で送金をしてしまったり、成功した経路も記録されていないため、同じ経路で送金しようとすらしない。 このため、CLNはLNDなどと比べて送金が不安定であったり、送金時間がかかったりする。しかし、現在、CLNはChannel Hintsを使った過去データからの経路探索の実装が進んでいるので、次期リリースが待ち遠しい。 https://github.com/ElementsProject/lightning/pull/7487
Purchased this article add3q50ur
Purchased this article i24z90y03
sutadonman purchased this article lvzbfej70
sutadonman purchased this article jdnih4anz
Purchased this article dkivx3ja0
🟧TAKA🐕 BITMAP🟧 purchased this article jdnih4anz
Purchased this article r8ns73l74
Purchased this article aj5kyiut7
Purchased this article xdkogpobo
