＜重要：リンクなどまではコピーしていないので、必ず原文も確認してください＞
UTXO & Account Models
UTXOとアカウントモデルについて
Previous Section Recap
前のセクションのまとめ
In the previous section, we looked at peer-to-peer network architecture, one of the main functional pillars of a decentralized distributed network like Bitcoin and Ethereum. The traditional "web2" model, typically relies on server-based network architecture.
前節では、BitcoinやEthereumのような分散型ネットワークの主要な機能柱の1つであるピアツーピアネットワークアーキテクチャについて見てきました。従来の「web2」モデルは、通常、サーバーベースのネットワーク・アーキテクチャに依存しています。
SERVER-BASED
サーバーベース
Centralized, clients send a request, central server responds back
中央集権型、クライアントがリクエストを送り、中央のサーバーがレスポンスを返す
Developers and applications can be de-platformed (look up what happened to Zynga at Facebook!). Data integrity is vulnerable since server owner can manipulate at whim
開発者やアプリケーションは、プラットフォームから外れる可能性がある（FacebookでZyngaに何が起こったか見てみよう！）。サーバーの所有者が気まぐれに操作できるため、データの完全性が損なわれる
Limits innovation
イノベーションを制限する
PEER-TO-PEER (P2P)
ピアツーピア (P2P)
Every node holds a copy of ledger, any node can read/write it under the right conditions (meets consensus rules)
各ノードが台帳のコピーを持ち、条件次第ではどのノードでも読み書きができる（コンセンサスルールを満たす）。
Data integrity is protected by consensus rules. Everyone keeps copy of ledger, no central location.
データの完全性はコンセンサスルールで保護される。誰もが台帳のコピーを保持し、中央には置かない。
Permissionless innovation
パーミッションレス・イノベーション
Nodes in a blockchain peer-to-peer network, like Bitcoin, can leave and re-enter the network at will. Bitcoin has nodes including full nodes and light nodes.
ビットコインのようなブロックチェーンのピアツーピアネットワークのノードは、自由にネットワークから離脱したり、再参入したりすることができます。ビットコインには、フルノードとライトノードというノードがあります。
full node: contains entire blockchain file.
フルノード：ブロックチェーン・ファイル全体が格納されています。
light node: does not require full blockchain file download, communicates with a full node to allow for lightweight clients to work (ie. wallets)
ライトノード：ブロックチェーンファイル全体をダウンロードする必要がなく、フルノードと通信して軽量クライアント（ウォレットなど）を動作させることができる。
With traditional web2 server based platforms, keeping track of user data and information is actually a lot easier than it is on the blockchain. This is because there is a single centralized server that stores the state of user accounts. There's no need for consensus or resolving discrepancies since there's only one central place that stores information.
従来のWeb2サーバーベースのプラットフォームでは、ユーザーのデータや情報を追跡することは、実はブロックチェーンよりもずっと簡単です。というのも、ユーザーアカウントの状態を保存するサーバーが一元化されているからです。情報を保存する場所が中央に1つしかないため、コンセンサスや不一致の解決は必要ないのです。
However, when you move to a decentralized system, the problem of storing user balances becomes tricky. Decentralized networks like Bitcoin and Ethereum need specific models for keeping track of the state of users. Bitcoin uses the UTXO model to keep track of user balances. Ethereum and other EVM chains use the account model to keep track of user balances. Let's dig in further...
しかし、分散型システムに移行すると、ユーザーの残高を保存する問題が厄介になる。ビットコインやイーサリアムのような分散型ネットワークでは、ユーザーの状態を把握するための特定のモデルが必要です。ビットコインはUTXOモデルを使用してユーザーの残高を追跡しています。イーサリアムや他のEVMチェーンでは、アカウントモデルを使用してユーザーの残高を追跡しています。さらに掘り下げてみましょう...
UTXO stands for "Unspent Transaction Output". You will see the term UTXO used a bit in this lesson! Bitcoin uses the UTXO model, so we like to include it because it helps us understand tradeoffs in blockchain storage models as well as it will help us compare and contrast to Ethereum and its use of the Account model.
UTXOは「Unspent Transaction Output」の略で、「未使用トランザクション出力」のことです。このレッスンでは、UTXOという用語が少し使われますよ。BitcoinはUTXOモデルを使っているので、ブロックチェーンのストレージモデルにおけるトレードオフを理解するのに役立ち、またEthereumとAccountモデルの使用との比較対照に役立つからです。
You thought we would already be learning Solidity, huh? Ah well, we are starting from scratch and digging into the fundamentals of what makes blockchains tick. It is important to understand these concepts as they will make you a better rounded smart contract engineer. Let's dig in...
すでにSolidityを学んでいると思われましたか？しかし、私たちはゼロから出発し、ブロックチェーンがどのようなものであるかを基礎から掘り下げています。これらの概念を理解することは、スマートコントラクトエンジニアとしてより博識になるために重要です。では、さっそく勉強していきましょう...
Transactions
トランザクション
The best place to start, before looking at how blockchains keep track of user balances, is the place where user balances begin: the transaction. Let's explore with the following question:
ブロックチェーンがユーザーの残高をどのように記録しているかを見る前に、ユーザーの残高の始まりである「取引」から始めるのが一番です。次の質問から探ってみましょう。
What do we need in a transaction?
Three main things:
トランザクションに必要なものは何でしょうか？
主なものは3つです。
1.amount: the amount to send to someone
金額：相手に送る金額
2.payer: the person sending the transfer amount
payer: 送金する人
3.payee: the person receiving the transfer amount
payee：送金額を受け取る人
Since we are working in systems based on really secure cryptography, we need ONE more thing to complete everything required for a successful blockchain transaction:
私たちは、本当に安全な暗号技術に基づいたシステムで仕事をしているので、ブロックチェーン取引の成功に必要なすべてを完了するためには、もう1つ必要なものがあります。
4.payer authorization: some sort of unfakeable authorization given by the initiator of the transaction
支払者承認：取引の開始者によって与えられるある種の偽りのない承認
This fourth item would just end up being the digital signature which is basically a hash that is extremely hard to replicate if you do not have the correct inputs - in this case, a user's private keys. Without the private keys, a payment authorization cannot occur. The only way to do it would be to "hack" basic cryptography which is practically impossible.
この4番目の項目は、基本的に正しい入力（この場合はユーザーの秘密鍵）がなければ複製が極めて困難なハッシュであるデジタル署名で終わります。秘密鍵がなければ、決済の承認はできない。そのためには、基本的な暗号技術を「ハッキング」するしかないのですが、それは現実的に不可能です。
Digital signatures are very important. Make sure to review Week 1, Day 2 if you still feel shaky on the subject!
デジタル署名はとても重要です。まだあやふやな感覚をもっている人は、1週目2日目の復習を必ずしてください
What is the purpose of a transaction?
To change some user state! If Alice sends Bob 5 $DAI, Alice's $DAI balance should go -5, Bob's should go +5. Alice's transaction is responsible for changing the state of their balances. Changing state is extremely important in blockchains (which are typically transaction-based networks!), so keep this in mind!
トランザクションの目的は何でしょうか？
ユーザーの状態を変更することです! アリスがボブに5ドルDAIを送ると、アリスのDAI残高は-5、ボブの残高は+5されます。アリスの取引は、二人の残高の状態を変更する責任があります。ブロックチェーン（典型的な取引ベースのネットワークです！）において、状態を変えることは非常に重要なので、このことを覚えておいてください。
Bitcoin, Ethereum and regular banks rely on transaction-based models to keep track of user balances. Let's take a further look below...
ビットコイン、イーサリアム、そして通常の銀行は、ユーザーの残高を把握するために、トランザクションベースのモデルに依存しています。以下、さらに詳しく見ていきましょう...。
Account-based Model
アカウント・ベース・モデル
If you have a bank account, you are very familiar with this model of keeping track of user balances. The account model follows just that: accounts. It tracks the balances of users based on their overall account state, without any tracking on what constitutes the actual balance itself. In other words, an account-based ledger would mark an entry like this:
もしあなたが銀行口座をお持ちなら、ユーザーの残高を追跡するこのモデルにはとても馴染みがあると思います。アカウントモデルは、まさに「アカウント」に従っています。このモデルでは、ユーザーの残高をアカウント全体に基づいて追跡し、実際の残高そのものを構成するものについては追跡しません。つまり、アカウントベースの台帳では、次のような記帳をすることになる。
Acct #12345 -> Name: Rick Sanchez -> Balance: $142.62
口座番号12345 -> 名前 リック・サンチェス → 残高：142.62ドル
Notice how the state of the account is kept very high-level? Rick's account balance is a dollar and cent amount and that's it. There is no further information tracked on what the breakdown of the the balance is, for example: $142.62 is one $100 bill, one $20 bill, two $10 bills, eight quarters, five dimes, two nickels, two pennies. When Rick goes to an ATM and withdraws from his balance, he gets it in whatever bills + change the bank has at hand - not in the exact change it took to make up that balance in the first place.
このように、口座の状態が非常に高度に保たれていることにお気づきだろうか。リックの口座の残高は、ドルとセントの金額で、それだけです。例えば、$142.62は100ドル札1枚、20ドル札1枚、10ドル札2枚、クォーター8枚、10セント玉5枚、ニッケル2枚、ペニー2枚というように、残高の内訳はそれ以上追跡されない。リックがATMで残高を引き出すとき、銀行が持っている紙幣と小銭で引き出しますが、最初にその残高を作るのに必要だった小銭ではありません。
What does a transaction look like in an account-based model?
アカウントベースのモデルでは、取引はどのようなものになるのでしょうか？
1.Alice has $60 total balance.
アリスは合計残高が60ドル
2.Bob has $20 total balance
ボブの総残高は$20
3.Bob sends Alice $5
ボブはアリスに$5を送ります。
4.Bob's balance is subtracted $5, if the remaining balance is greater then 0, proceed, else revert
ボブの残高から$5が引かれ、残りの残高が0より大きければ処理を続行、そうでなければ元に戻す
5.lice balance is summed $5
アリスの残高の合計が$5
6.The ledger is marked in both ends to update total balances and that is the end of the transaction in an account-based model.
元帳は両端で合計残高を更新するようにマークされ、アカウントベースのモデルでの取引はこれで終了です。
This might seem weird. Why would we want to keep track of these details for something as simple as a total balance? We'll look at a model for keeping user balances that does include this feature: the UTXO model.
これは奇妙に思えるかもしれません。残高の合計という単純なものに対して、なぜこのような詳細を記録しておく必要があるのでしょうか？ここでは、このような機能を持つ、ユーザーの残高を管理するためのモデル、UTXOモデルについて見ていきます。
UTXO-based Model
UTXOベースモデル
Ethereum uses the account-based model, while Bitcoin uses UTXOs (short for Unspent Transaction Outputs) to keep track of user state/balances.
Ethereumはアカウントベース、BitcoinはUTXO（Unspent Transaction Outputsの略）を使ってユーザーの状態や残高を管理するモデルです。
The UTXO model differs pretty drastically from the account model. It's a little bit more complex - mainly because it is not a familiar interface like the account model is! Yet it does set up some interesting features...
UTXOモデルは、アカウントモデルとはかなり大きく異なります。アカウントモデルのように使い慣れたインターフェースでないため、少し複雑です。しかし、いくつかの興味深い機能が設定されています...
What is a UTXO? 🤔**
UTXOとは？🤔**
Alice sends Bob 5 BTC in the form of a transaction relayed to the Bitcoin network. At this point, if the transaction is valid (Alice has > 5 BTC, Alice owns the relevant private keys and can produce a signature, etc), Alice is signaling an intent to change user state. When the Bitcoin network mines Alice's transaction, Bob is credited with a UTXO worth 5 BTC. This is how the Bitcoin network keeps track of user balances - it keeps a really big long set of UTXOs - outputs out of state-changing transactions that credit users with a certain amount of BTC.
アリスはボブに5BTCをビットコインネットワークに中継されるトランザクションの形で送ります。この時点で、その取引が有効であれば（アリスが5BTC以上を持っている、アリスが関連する秘密鍵を所有しており署名を生成できる、など）、アリスはユーザーの状態を変更する意思を示していることになります。ビットコインネットワークがアリスの取引を採掘すると、ボブには5BTC相当のUTXOがクレジットされる。これは、ビットコインネットワークがユーザーの残高を追跡する方法です。それはUTXOの本当に大きな長いセットを保持します - ユーザーに一定量のBTCをクレジットする状態変更トランザクションから出力されます。
So when people say: "I own 3 bitcoins", they should really be saying: "I own some UTXOs that allow me to spend 3 bitcoins." - or using the Drake meme:
だから、人々が言うとき、「私は3枚のビットコインを所有しています。「私は3ビットコインを所有しています」と言うとき、本当は "3ビットコインが使えるUTXOをいくつか持っている "と言うべきでしょう。- あるいは、ドレイクのミームを使って
Important notes on UTXOs:
UTXOに関する重要な注意事項
1.All UTXOs are non-fungible (fun fact: the first NFT collection ever was... Bitcoin!)
UTXOはすべて非代替性です（面白い事実：史上初のNFTコレクションは...ビットコインでした！）。
2.To spend a UTXO, you must refer back to that specific UTXO.
UTXO を使用するには、その特定の UTXO を参照する必要があります。
A user's UTXOs are scattered across blocks.
ユーザーのUTXOはブロックに散らばっています。
3.Once a UTXO is "consumed", any leftover change from the transaction creates new UTXOs representing the change amounts
UTXOが「消費」されると、その取引で残ったおつりが、そのおつりの金額を表す新しいUTXOを生み出します。
4.A UTXO, often referred to as a "coin", can only be spent ONCE. No double-spending!
UTXOは、しばしば「コイン」と呼ばれ、一度しか使用できません。二重消費はできません
5.In Bitcoin, each UTXO has a script associated with it
ビットコインでは、各UTXOにスクリプトが関連付けられています。
Scripts are basically hard-programmed code that each UTXO stores. They usually contain the conditions under which to unlock the UTXO for further spending. More resources on Bitcoin Script.
スクリプトは基本的に、各UTXOが保存するハードプログラムされたコードです。スクリプトには通常、UTXOのロックを解除してさらに使用できるようにするための条件が含まれています。ビットコインスクリプトに関するその他のリソースはこちらを参照ください。
Account vs UTXO model
ACCOUNTS
アカウント
User Balances Overall Account State (ie. Alice has 4.2 ETH)
ユーザー残高 アカウント全体の状態 (例: アリスは4.2ETHを持っている)
Pros More intuitive, easier to quickly understand
長所 より直感的で、すぐに理解しやすい。
Cons Replay Attacks (someone could re-)
短所 リプレイアタック(誰かが再攻撃できる)
UTXOS
User Balances Specific UTXOs (ie. Alice has 29 UTXOs that amount to 2.65 BTC)
ユーザー残高 特定のUTXO (例: アリスは2.65 BTCに相当する29 UTXOを持っている)
Pros Very good privacy if user uses a new address per tx
長所 ユーザがTxごとに新しいアドレスを使用する場合、非常に良いプライバシー
Cons UTXOs are stateless, which complicates state-heavy designs
短所 UTXOはステートレスであるため、ステートヘビーな設計が複雑になる。
Conclusion
まとめ
Deciding what model to go with is a game of design tradeoffs. Ethereum uses the account-based model transactions must be more flexible to account for the many moving pieces of state in the system. Bitcoin uses UTXOs as it is a network purposefully designed to be as simple and stateless as possible.
どのモデルを採用するかは、設計のトレードオフのゲームである。Ethereumはアカウントベースのモデルを使用しており、トランザクションはシステム内の状態の多くの可動部分を考慮し、より柔軟でなければなりません。ビットコインはUTXOを使用していますが、これはネットワークが可能な限りシンプルでステートレスであるように意図的に設計されているためです。
<next chapter>
Coding the UTXO Model
UTXOモデルのコーディング
Unspent Transaction Outputs
未使用のトランザクション出力
Bitcoin uses Unspent Transaction Outputs for handling user ownership of coins. This is opposed to an account based model used by Ethereum, which tracks balances of particular addresses.
ビットコインは、ユーザーのコインの所有権を処理するためにUnspent Transaction Outputsを使用します。これは、特定のアドレスの残高を追跡する、イーサリアムで使用されているアカウントベースのモデルとは対照的です。
Let's consider a couple of examples.
いくつかの例を考えてみましょう。
UTXO Example 1
UTXO の例 1
Bob runs a Bitcoin Miner. He successfully computes a block and rewards himself with 12.5 BTC as per the emission rules. This is a brand new Unspent Transaction Output (UTXO) Bob has introduced to the system.
ボブはビットコインマイナーを実行している。彼はブロックの計算に成功し、排出規則に従って12.5 BTCを自分に報酬として与えました。これは、Bobがシステムに導入した全く新しいUnspent Transaction Output (UTXO)です。
Now let's say Bob wants to send Alice 6.0 BTC. He can do so by using his UTXO with 12.5 BTC. But, wait, Bob doesn't want to send Alice 12.5 BTC! How do we handle the remainder?
さて、ボブがアリスに6.0BTCを送りたいとしましょう。彼は12.5BTCのUTXOを使うことでそれが可能になります。しかし、ボブはアリスに12.5BTCを送りたいわけではありません! 残りはどうすればいいのでしょうか？
As it turns out Bitcoin allows you to designate multiple outputs per transaction. In this particular transaction, we'll create one UTXO of 6.0 BTC for Alice and another UTXO of 6.5 BTC for Bob (the remainder). Then, we'll mark the UTXO for 12.5 BTC as spent since it was used as an input for the transaction. Neat!
ビットコインでは、1回の取引で複数のアウトプットを指定することができます。このトランザクションでは、アリスに6.0BTCのUTXOを1つ、ボブに6.5BTCのUTXO（残金）をもう1つ作成することにします。そして、12.5BTCのUTXOはトランザクションの入力として使用されたので、使用済みとマークします。すっきりしましたね。
UTXO Example 2
UTXOの例 2
One thing that can often happen when using this model, is users end up with a lot of small UTXOs. As Alice transacts with the network her, UTXO breaks up into smaller outputs until she's left with 3 UTXOs of values 1.0 BTC, 1.5 BTC, and 0.8 BTC.
このモデルを使うときによく起こることは、ユーザーがたくさんの小さなUTXOを持つことになることです。アリスがネットワークで取引をすると、UTXOはより小さな出力に分解され、1.0BTC、1.5BTC、0.8BTCの3つのUTXOを残すことになりました。
Let's say that Alice wants to purchase something for 3.0 BTC. She can do so by specifying many inputs to the transaction. She can put all three of her UTXOs as inputs into the transaction for a to total of 3.3 BTC. After the transaction is executed, she'll recieve a new UTXO of 0.3 BTC and her previous inputs will all be marked as spent.
アリスが3.0BTCで何かを買いたいとします。彼女は取引に多くの入力を指定することによって、それを行うことができます。彼女は3つのUTXOを入力としてトランザクションに入れ、合計3.3BTCにすることができます。取引実行後、彼女は0.3BTCの新しいUTXOを受け取り、以前の入力はすべて使用済みとマークされる。
Ok that's enough examples for now! Let's learn for ourselves with some coding exercises.
さて、これで例題は十分でしょう。では、コーディングの練習をしながら、自分自身で学んでいきましょう。
<next chapter>
UTXO MODEL
Transaction Outputs
取引出力
Now it's time to create an object for Transaction Outputs(TXOs)!
さて、いよいよTransaction Outputs(TXOs)用のオブジェクトを作成します。
Using a Bitcoin Block Explorer you can look up TXOs on the actual network. If we wanted to look up UTXOs for a particular address, for instance:
Bitcoin Block Explorer を使えば、実際のネットワーク上の TXO を調べることができます。例えば、あるアドレスのUTXOを調べたい場合:
The value after active= is an address. This particular address was the one Satoshi used when they mined the first Bitcoin block.
active=の後の値がアドレスです。この特定のアドレスは、Satoshiが最初のBitcoinブロックを採掘したときに使用したものです。
Your Goal: Create a TXO class
目標：TXOクラスの作成
Let's complete the constructor and spend methods for the TXO class in the TXO.js file.
TXO.js ファイルで、TXO クラスのコンストラクタと spend メソッドを完成させましょう。
1.The constructor should store the values passed into it on properties of the same name. It should also create a property spent and default it to false.
コンストラクターは、渡された値を同じ名前のプロパティに格納する必要があります。また、spentというプロパティを作成し、デフォルトをfalseにする必要があります。
2.The spend function should set the spent property to true. For example:
const txo = new TXO("1FNv3tXLkejPBYxDHDaZz6ENNz3zn3G4GM", 10);
spend関数は、spentプロパティをtrueに設定する必要があります。例えば、以下のようになります。
console.log( txo.owner ); // 1FNv3tXLkejPBYxDHDaZz6ENNz3zn3G4GM
console.log( txo.amount ); // 10
console.log( txo.spent ); // false
txo.spend();
console.log( txo.spent ); // true
Notice how spent is initially false when we create the new TXO. After invoking the spend function, spent should be set to true.
新しいTXOを作成したとき、spentが最初はfalseであることに注目してください。spend関数を呼び出した後、spentはtrueに設定されなければなりません。
<next chapter>
2: Spent TXOs
Transactions
取引について
Transactions on the Bitcoin network can have many inputs and many outputs.
ビットコインネットワーク上の取引は、多くのインプットと多くのアウトプットを持つことができます。
You can take a look at this Bitcoin Transaction for an example of one with many outputs.
このビットコイン取引は、多くの出力を持つものの例として見ることができます。
This combined with a scripting system on each transaction allows Bitcoin users to engage in more complex financial agreements than one individual simply sending money to the other.
これは、各トランザクションのスクリプトシステムと組み合わせることで、ビットコインのユーザーは、ある個人が他の個人にお金を送るだけでなく、より複雑な金融契約に従事することができます。
For your average transaction, the Script simply requires that new UTXOs can only be spent by the associated address.
平均的な取引では、スクリプトは単に新しいUTXOが関連するアドレスによってのみ使用できることを要求しています。
Your Goal: Ensure Inputs are UTXOs
目標: 入力がUTXOであることを確認する
On this stage, we introduce a new file Transaction.js.
このステージでは、新しいファイルTransaction.jsを紹介します。
In the Transaction constructor you'll see two arguments passed in: inputUTXOs and outputUTXOs. Both of these objects are arrays containing instances of transaction outputs.
Transactionのコンストラクタには、inputUTXOsとoutputUTXOsという2つの引数が渡されています。これらのオブジェクトは両方とも、トランザクション出力のインスタンスを含む配列である。
1.Store inputUTXOs and outputUTXOs on the transaction object.
inputUTXOsとoutputUTXOsをトランザクションオブジェクトに格納します。
2.In the execute function do one thing for now: ensure that none of the inputUTXOs are already spent. We can't allow double-spending TXOs!
execute関数では、とりあえず1つのこと、つまりinputUTXOのどれもがすでに使われていないことを確認します。TXOの二重消費は許されない!
3.Throw an error in execute if any input TXO is already spent.
入力されたTXOがすでに使用されている場合、execute関数でエラーを投げる。
The terminology between UTXO and TXO can sometimes get confusing. Remember that a TXO is just the nomenclature for a UTXO that is already spent!
UTXOとTXOの用語は、時に混乱することがあります。TXOは、すでに使用されたUTXOの名称に過ぎないことを忘れないでください!
<next chapter>
3: Sufficient Amount
十分な量
Inputs & Outputs
入出力
With a multitude of input and output UTXOs allowed in every transaction, there are many possibilities of exchange that exist!
トランザクションごとに多数の入力と出力のUTXOが許可されているため、多くの交換の可能性が存在する!
Bitcoin wallet software will sometimes choose to include many input UTXOs just to aggregate them into one bigger UTXO to send back to the owner.
ビットコイン財布ソフトウェアは、所有者に送り返すためにそれらを1つの大きなUTXOに集約するために、多くの入力UTXOを含めることを選択することがあります。
For instance, if you have five UTXOs, each with amounts of 0.1 BTC, your wallet may choose to combine them into 0.5 BTC on the next transaction. Behind the scenes magic
例えば、5つのUTXOがあり、それぞれが0.1 BTCの金額である場合、ウォレットは次の取引でそれらを0.5 BTCにまとめることを選択することがあります。舞台裏の魔法🐇🎩
The important part is ensuring there is enough total value in the input UTXOs to cover the total amount in the output UTXOs.
重要なのは、インプットUTXOの合計金額がアウトプットUTXOの合計金額をカバーするのに十分な量であることを確認することです。
Your Goal: Ensure Sufficient Input
あなたの目標：十分なインプットを確保すること。
1.Let's make sure that the inputUTXOs have enough total value in them to cover the total value of the outputUTXOs.
入力UTXOに、出力UTXOの総量をカバーするのに十分な総量があることを確認しよう。
If the total value of the inputs is less than the total value of the outputs, throw an error in the execute function.
入力の合計値が出力の合計値より小さい場合、execute関数でエラーを投げる。
(参考MDN)
<next chapter>
Successful Execute
実行の成功
Successful Transaction
トランザクションの成功
When a transaction is successful and mined to the blockchain, the output UTXOs become new TXOs that are ready to be spent. The input UTXOs need to be marked as spent, to ensure that they are not spent again!
トランザクションが成功し、ブロックチェーンに採掘されると、出力されたUTXOは新しいTXOになり、使用できるようになります。入力されたUTXOは、再び使用されないように、使用済みとマークされる必要があります。
After all, the whole purpose of the blockchain is to fix the double-spend problem
結局のところ、ブロックチェーンの全目的は、二重支出の問題を解決することです。
Your Goal: Mark Inputs as Spent
あなたの目標：入力を使用済みとしてマークする
If no errors are thrown during the execute function of the transaction, then it is successful
トランザクションの実行関数でエラーが発生しなければ、それは成功である。
<next chapter>
5: Miner's Fee
採掘者手数料
At this point you may be wondering why in the third stage we only required that the total input amount be more than than the total output amount.
ここで、なぜ第3ステージでは入力の総量が出力の総量より多ければいいのか、疑問に思うかもしれない。
Shouldn't we also throw an error when the output amount turns out to be less?
出力が少ないとエラーにならないのでしょうか？
Nope! Actually, the remainder is given to the miner!
そうではない。実は、余った分は採掘者に渡されるんです。
This is a design choice in the Bitcoin system. It is referred to as the transaction fee.
これは、ビットコインのシステム設計上の選択です。これは取引手数料と呼ばれています。
The transaction fee can help expedite your request. A miner is much more likely to include your transaction in their next block if you include a nice hefty prize for them to collect!
取引手数料は、あなたの依頼を迅速にするのに役立ちます。採掘者は、あなたの取引を次のブロックに含める可能性が高くなります。
Bitcoin has a controlled supply. For a limited time there is a reward for the miner in every block. At a certain point, this will stop and the only reward for the miner will become the transaction fees.
ビットコインは供給が制限されています。限られた期間、すべてのブロックに採掘者への報酬があります。ある時点で、これは停止し、採掘者の報酬は取引手数料のみとなります。
Your Goal: Calculate the fee!
目標：手数料を計算する
At the end of the execute function, calculate the fee as the sum of all the inputs minus the sum of all the outputs.
execute関数の最後で、すべての入力の合計からすべての出力の合計を引いたものを手数料として計算する。
1.Given that we throw an error if the inputs are insufficient, this number should be at least zero. Any time outputs are less, this should be a positive fee.
入力が不十分な場合はエラーを投げるので、この数字は少なくともゼロでなければならない。また、出力が少ない場合は、料金をプラスにする必要があります。
2.Store the fee amount in a property called fee on the transaction itself.
手数料の金額は、トランザクション自体のfeeというプロパティに格納する。
For example:
例えば:
const iTXO = new TXO(fromAddress, 5);
const oTXO = new TXO(toAddress, 3);
const tx = new Transaction([iTXO], [oTXO]);
tx.execute();
console.log( tx.fee ); // 2
Nice tip!
いい手数料!
<next chapter>
Further Reading on UTXOs
UTXOに関するその他の情報
Real Transactions
実際の取引
We can take a look at the Genesis Block and see that there was a coinbase transaction sent to 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa which was never spent!
Genesis Blockを見てみると、1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNaに送られたcoinbaseトランザクションがありましたが、これは使われなかったことが確認できます
Here's some more information about the Genesis Block. The scriptPubKey is also called the "Witness Script" or the "Locking Script".
ここで、Genesis Blockについてもう少し詳しく説明します。scriptPubKeyは、「Witness Script」または「Locking Script」とも呼ばれます。
For each Locking Script there should be an Unlocking Script that will unlock the UTXO and allow it to spent. Typically, all the unlocking script needs to provide is a signature that verifies ownership of a public key, and then the public key needs to match the address after being hashed twice.
各ロックスクリプトには、UTXOのロックを解除して使用できるようにするアンロッキングスクリプトが必要です。通常、ロック解除スクリプトに必要なのは、公開鍵の所有権を確認する署名と、公開鍵が2回ハッシュ化された後にアドレスと一致することです。
If you look down in that wiki article, you'll see that the Genesis Block Coinbase UTXO is not included in client's database, so it cannot be spent! For more information on that see here.
そのwikiの記事の下を見ると、Genesis Block Coinbase UTXOはクライアントのデータベースに含まれていないため、使うことができないことがわかりますね その辺の詳細はこちらをご覧ください。
Bitcoin Script
ビットコインスクリプト
The Bitcoin Script language is meant to be a simple stack-based language that has no loops so it will always resolve and there are no denial of service attacks. The language is basically a list of function-like operation codes, that take arguments off the stack and operate on them. See the full list of operation codes here.
ビットコインスクリプト言語は、ループのないシンプルなスタックベースの言語であるため、常に解決され、サービス拒否攻撃はありません。この言語は基本的に関数のような操作コードのリストで、スタックから引数を取り、それに対して操作を行います。操作コードの全リストはこちら。
You can find some interesting background on Bitcoin Script in this Stack Overflow answer here. The author of that answer mentions a bug with OP_RETURN and concatenating the unlock and locking scripts. You can find more background information on that here
Bitcoin Scriptに関する興味深い背景は、Stack Overflowの回答で見ることができます。この回答の著者は、OP_RETURNとロック解除およびロックスクリプトの連結に関するバグに言及しています。それに関する詳細な背景情報は、こちらで確認できます。
Someone made a JavaScript implementation of Script. Pretty cool!
ある人がScriptのJavaScript実装を作りました。かなりイケてる!
Two common forms of transaction scripts for Bitcoin are the Pay-to-Pubkey Hash and Pay-to-Script Hash.
ビットコインのトランザクションスクリプトには、Pay-to-Pubkey HashとPay-to-Script Hashという2つの一般的な形式があります。