Transactions in Grin Explained
Editor's Note: This article comes fromEthereum enthusiastEditor's Note: This article comes fromBrandon ArvanaghiEthereum enthusiast
(ID: ethfans), author:
, translation & proofreading: stormpang & Min Min, published with permission.
Editor's note: Grin is a new cryptocurrency based on the MimbleWimble protocol. This article is a detailed tutorial, explaining step by step how transactions in the MimbleWimble protocol are structured, and how to use cryptography to ensure that the currency is not double-spend without revealing the addresses and transaction amounts of both parties, and that only the currency owner can Spend currency.
This article aims to share the operating principle of Grin transactions and help everyone understand how Grin transactions actually operate.
The output of a Grin transaction is a Pederson commitment, which takes the following form:
image description
- A Grin output is a Pedersen promise. -
Perdersen promises are a great way to hide information. If you're hearing the concept of a Perdersen commitment for the first time, whenever you see the word, think of the concept of a "shielded value" What).
The following text is taken from Grin's wiki (the best primer for understanding how Grin transactions work).
Suppose we choose a very large number k as the private key and k * H as the corresponding public key. Even if someone knows the value of the public key k * H, it is almost impossible to deduce the value of k from it...
r is the private key used as the blinding factor, G is a fixed point on the elliptic curve, and their product r * G is the public key of r on this curve.
v is the input or output value, H is another fixed point on the elliptic curve...
Knowing the private key k and private key j, then (k+j) * H = k * H + j * H, that is, the public key generated by multiplying the sum of the two private keys with the fixed point H ((k+j) * H) ) is equal to the sum k * H + j * H of the two public keys generated by multiplying the two private keys with the fixed point H respectively.
For a more in-depth study of cryptography, you can read the ECC primer blog. In short, to spend a Grin output, both the blinding factor (r) and the Grin transaction amount (v) must be known. These two values cannot be deduced backwards by cracking promises. Therefore, the output of Grin can only be spent if these values are known in advance.
Let's say this output contains 40 Grin, using a blinding factor of 20.
(Interlude: The actual number of Grin sent is an integer multiple of the atomic unit 1 NanoGrin. Here, for the sake of simplicity, I use an integer number of Grin as an example):
- In this output, the blinding factor is 20 and the number of grins is 40. -
Looking at the output of the Grin transaction on the Grin browser, we will find that the actual output is not presented through a clear formula like the above picture. Here's what the Grin output really looks like:
-Grin output (in "commit" column). -
Again, it is impossible to deduce "20" (blinding factor) or "40" (amount of Grin) from this output.
secondary title
Suppose the output we just mentioned belongs to Alice. Now, Alice wants to send 25 of these 40 Grin to Bob. For simplicity, let's ignore the transaction fees for miners.
If you have a $5 bill and buy something for $3, you get $2 in change. This is how transactions in the Bitcoin system work, and Grin is no exception. If Alice wants to take 25 Grin out of her unspent transaction output 40 Grin and send it to Bob, she will also create a new unspent transaction output in this transaction, and return the remaining 15 Grin (change) to herself the address of.
image description
15 Grin in this transaction will go back to Alice, meaning only she can control and spend the 15 Grin again. In other words, it must be impossible for Bob to spend Alice's change. To do this, Alice must create a new blinding factor for her change output. Suppose Alice picks 34 .
Knowing both r (the blinding factor of her change output) and v (the amount of Grin to give change to), Alice has all the information needed to create the change output (co), which will be recorded as an output on the blockchain superior. The same goes for the 25 Grin output that Alice is about to send to Bob.
image description
As I mentioned earlier, an output can only be spent if the blinding factor it uses is known. Alice knows the blinding factor (20) of the output she wants to spend, but she needs a way to prove to others in the Grin system that she knows.
That's why she needs to create a completely separate calculation that solves for her total blinding factor. This is the blinding factor Alice just created for her change output (34), minus the blinding factor of the output she wants to spend (20).
image description
- Total number of blinding factors for Alice. -
rs (s means the sender, ie Alice) represents the total number of Alice's blinding factors, which is 14 in this example. (Interlude: I intentionally left out the kernel offset.)"Alice sends the following information to Bob. Actually, Grin data is not divided into "Metadata" and
Data (Data)" field, but for the sake of clarity, this article deliberately distinguishes the two.
image description
-All the information that Alice needs to send to Bob in the first step of the Grin transaction. -
Metadata field:
Amount to send: The amount of Grin Alice wants to send to Bob (25 in this example).
Transaction Unique ID (TX UUID): A unique identifier used by Alice and Bob when sending data back and forth to identify this transaction.
Transaction fee (TX fee): transaction fee (we will not discuss it in this tutorial).
Lock height (lock_height): the block number where the transaction takes effect.
Data (Data) field:
Transaction Inputs (TX Inputs): Alice uses single or multiple unspent outputs as inputs to a transaction sent to Bob.
Change output (co): Alice’s change output
ks • G: Alice's nonce ks is multiplied by the generation point G, and the obtained value is the Pedersen commitment of this nonce.
rs • G: Alice's total blinding factor rs is multiplied by the generation point G, and the obtained value is the Pedersen commitment of this rs.
Bob's actions
After receiving the information sent by Alice, Bob concatenates the two variables TX fee and lock_height to generate M (the "Message" of the transaction).
image description
Bob chooses a blinding factor rr for the 25 Grin he will receive from Alice (r stands for receiver ie Bob). Suppose he chooses 11. At the same time, he also chooses his own random nonce kr (r stands for receiver).
Same as Alice's operation, Bob creates a Pedersen commitment by multiplying the two values rr and kr by the generator point G respectively. With these data, Bob can generate the Schnorr challenge corresponding to this transaction, represented by the variable e:
image description
- Trading Schnorr Challenge. -
The Schnorr challenge SHA256 hashes the following information in order:
transaction news.
The sum of the commitments for Bob's (chosen for his 25 Grin output) blinding factor and Alice's total blinding factor commitment.
Bob generates his own Schnoor signature for the transaction through e, which is sr (r stands for receiver). Although sr is Bob's full signature, we call it Bob's partial signature because it is ultimately combined with Alice's partial signature to create the signature of the entire transaction.
- Bob's partial signature on the transaction. -
When Alice finally receives sr, there is no way to deduce the actual value of kr or rr. Bob sends the following to Alice:
image description
- Bob sends his partial signature, the commitment corresponding to the nonce, and the commitment corresponding to the blinding factor of 25 Grin to Alice. -
In order, the content sent includes:
sr: Bob's partial signature.
kr • G: The commitment corresponding to the nonce chosen by Bob.
rr • G: The commitment corresponding to the blinding factor of 25 Grin that Bob is about to receive.
Alice now has everything she needs to compute e and the Schnorr challenge for this transaction. After computing e locally, Alice is able to verify Bob's partial signature.
As you recall, Bob's partial signature sr consists of the following:
- Bob's partial signature on the transaction. -
Based on the properties of elliptic curves we described earlier, the equation still holds after Alice multiplies both sides of the equation by the generator point G.
image description
- Alice multiplies both sides of the equation by the generating point G. -
Because Alice has already received kr • G (commitment corresponding to the nonce selected by Bob) and rr • G (commitment corresponding to the blinding factor of 25 Grin that Bob will receive) from Bob, and has calculated locally Given e, she can verify Bob's partial signature by simply multiplying sr by the generator point G to ensure that it is equal to the value on the right side of the equation.
By doing the above, Alice can prove that:
Bob knows the amount of Grin he will receive (25).
Bob knows his nonce value.
...At this point, Alice has verified Bob's partial signature without knowing the nonce and blinding factor Bob chose.
Alice then generates her own partial signature:
image description
-Alice's partial signature on the transaction. -
Alice can now generate a signature for the transaction, which contains her and Bob's partial signatures:
The transaction signature consists of the sum of Alice's and Bob's partial signatures and the sum of commitments corresponding to their respective nonces.
In order, the signature contains:
The sum of commitments corresponding to Alice's and Bob's nonces (neither of them knows the other's nonce value).
After merging, the transaction signature can be expressed as follows:
image description
-Transaction Signature-
Among them, s = ss + sr, k = ks + kr.
Remember this signature -- you'll soon know what it means.
Transaction complete
Digital currencies require "memory" -- that is, when you send money to one person, you cannot send the same money to someone else. By using Grin, we hide how much Grin is sending and who is receiving it. So, how do we prove that this money has not been "double spent" or created out of thin air?
In a Grin transaction, after subtracting all outputs from inputs, the amount of remaining Grin should be equal to 0. Take the $5 bill again as an example:
(34•G) + (15•H) + (11•G) + (25•H) - (20•G) - (40•H) = (25•G) + (0•H)
$3 to cashier (output) + $2 change back to me (output) - $5 bill (input) = 0
Similarly, a legitimate Grin transaction also satisfies the above equation. So, how can we verify without exposing the actual value? Let's take a look at the inputs and outputs of a transaction between Alice and Bob:
If the sum of the outputs of a Grin transaction minus the sum of the inputs yields a valid elliptic curve public key, then you know that the value of v must be cancelled. If the right-hand side of the equation is not of the form n•G + 0•H for some known value n, you'll know the deal is illegal. This means that either the total output is greater than the total input (e.g. you pay $5 and the cashier takes $3 and gives you $10 instead), or the total input is greater than the total output (e.g. you pay $5, the cashier takes $3, but doesn't give you money).
Remember the signature drawn above?
image description
This signature actually signs the commitment corresponding to the excess blinding factor I just mentioned, which we explain below.
Remember, when you multiply both sides of the equation for Bob's partial signature by G, you get the following equation.
-Both sides of the equation are multiplied by Bob's partial signature after generating point G-
Similarly, when you multiply both sides of the equation of Alice's partial signature by G, you will get the following equation.
image description
sr•G + ss•G = (kr • G) + (ks • G) + (e • (rr•G + rs•G))
- Both sides of the equation are multiplied by Alice's partial signature after generating point G. -
What happens if you add the two equations together? You will get:
where rr is Bob's blinding factor, rs is the total number of Alice's blinding factors, and rr•G + rs•G is equal to (rr + rs)•G.
sr•G + ss•G = (k•G) + (e • (r•G))
Bob's blinding factor corresponds to a commitment of 11•G. Alice's total blinding factor corresponds to a commitment of 14•G, and the two are added together to get 25•G (representing the excess blinding factor commitment of the entire transaction). Therefore, if the sum of sr (Bob's partial signature) and ss (Alice's partial signature) is equal to the commitment corresponding to the excess blinding factor, it can prove that the entire transaction is legal.
sr•G + ss•G = (k•G) + (e • (25•G))
Simplifying this equation further, we get:
or:
Then you just need to check whether both sides of the equation are equal.
Remember that all variables in the equation (sum of partial signatures, parts of e, commitments for excess blinding factor, commitments for sum of nonces) are visible to everyone, so anyone can make verify. We can verify the transaction without knowing either Alice's blinding factor or Bob's blinding factor. By adding their partial signatures and verifying that the sum is equal to the commitment corresponding to the excess blinding factor, we can prove that:
When Alice and Bob create the transaction, they both know the blinding factors of their respective outputs. This means that they are able to spend the new output produced by the transaction so that the output is not locked.
The information we just used to verify the transaction is placed in the transaction kernel.
secondary title
transaction kernel
In addition to the output, the transaction kernel is another part of the information generated by the Grin transaction. Each transaction generates a transaction kernel, but the transaction kernel associated with it cannot be found by querying an output on the Grin blockchain. Every Grin transaction contains a transaction kernel and proof that no excess Grin was created out of thin air.
The following information will be stored in the transaction kernel:
The transaction fee (transaction fee) and lock height (lock_height). (Interlude: If it is a Coinbase transaction, these two parts of the information will not be included).
Summarize
secondary title
Summarize
After all these operations, only the following transaction-related information will be broadcast to the network:
input spent.
The newly generated output.
Transaction core.
Kernel offsets (which I do not describe here).
