commit 97b2090cc91d3274e6d1918ea07767428aeb7ec8 parent 4cf9dd00afa1e701da415bc2cdad7518bac03c17 Author: Antoine A <> Date: Thu, 26 May 2022 21:30:22 +0200 typos Diffstat:
40 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/docs/report.tex b/docs/report.tex @@ -85,7 +85,7 @@ Bitcoin is focused on currency transfer transactions and some people wanted to d \subsection{Blockchain} -At the heart of these currencies is a blockchain. A blockchain is an append-only database composed of a list of linked records called blocks. The content of each block, except the genesis block (the first block), depends on the content of its parent block. This chained dependency enforces the immutability of the database, preventing retroactive modification whiteout altering all subsequent blocks. Cryptocurrency transactions takes effect when they are stored inside those blocks. +At the heart of these currencies is a blockchain. A blockchain is an append-only database composed of a list of linked records called blocks. The content of each block, except the genesis block (the first block), depends on the content of its parent block. This chained dependency enforces the immutability of the database, preventing retroactive modification without altering all subsequent blocks. Cryptocurrency transactions take effect when they are stored inside those blocks. \subsection{Consensus} @@ -95,7 +95,7 @@ The blockchain itself is just a storage system. To make it a \ac{DLT}, it needs This mechanism consists in making the process of appending a block to the blockchain heavy in computation (mining) by requiring brute force hashing for example. Nodes willing to invest their computation power (miners), work to extend the chain they consider the current state. Over time, the longest chain will be the one where the majority of computing power has been invested, which means that it is the one followed by the majority of miners. -This falls short as soon as one node control significantly more computation power than others. This node will not be able to create invalid blocks, because the other nodes will reject them, but will be able to revise transaction history and control the mining of future transactions. This is a majority attack also known as the 51\% attacks. +This falls short as soon as one node control significantly more computation power than others. This node will not be able to create invalid blocks, because the other nodes will reject them, but will be able to revise transaction history and control the mining of future transactions. This is a majority attack also known as the 51\% attack. Another problem is that miners are incentivized to invest more and more computing power, which leads to ever-increasing energy consumption and ecological impact. These problems have motivated the search for another mechanism: proof of stake. @@ -107,11 +107,11 @@ The effectiveness and security of this mechanism have yet to be proven, but Ethe \subsubsection*{Block time} -Achieving consensus within the peer-to-peer network requires broadcasting the state of the blockchain to most nodes. This coordination takes some time, and we do not want blocks to be mined faster than the network can keep up. An adaptive difficulty algorithm is used to keep the block time close to a constant, by changing the amount of computation required to mine a block. On Ethereum, the block time is about 12 to 14 seconds \footnote{https://ethereum.org/en/developers/docs/blocks/\#block-time}. On Bitcoin, the block time is about 10 minutes. This limitation combined with a block size limit, creates a transaction rate and a blockchain size growth limit that is difficult to change without disrupting the security of the system. +Achieving consensus within the peer-to-peer network requires broadcasting the state of the blockchain to most nodes. This coordination takes some time, and we do not want blocks to be mined faster than the network can keep up. An adaptive difficulty algorithm is used to keep the block time close to a constant, by changing the amount of computation required to mine a block. On Ethereum, the block time is about 12 to 14 seconds\footnote{https://ethereum.org/en/developers/docs/blocks/\#block-time}. On Bitcoin, the block time is about 10 minutes. This limitation combined with a block size limit, creates a transaction rate and a blockchain size growth limit that is difficult to change without disrupting the security of the system. \subsubsection*{Reorganization} -These decentralized consensus mechanisms lead to the creation of competing blockchain states. When two miners broadcast a new valid block in a short period of time, one part of the network may receive them in a different order than another part. As nodes will follow the first valid block they found, we have a blockchain fork where two different blockchain state are followed in the network (Figure~\ref{fig:reorg}). +These decentralized consensus mechanisms lead to the creation of competing blockchain states. When two miners broadcast a new valid block in a short period of time, one part of the network may receive them in a different order than another part. As nodes will follow the first valid block they found, we have a blockchain fork where two different blockchain states are followed in the network (Figure~\ref{fig:reorg}). \begin{figure}[H] \begin{center} @@ -125,12 +125,12 @@ Over time, one fork will become longer than the other, and nodes will follow the \subsection{Mining incentive} -A minimum amount of mining power is required for the cryptocurrency to work. Without new blocks, there can be no new transaction. The more mining power and diversity (different miners), the more resistant the \ac{DLT} is to attacks. Since mining is an expensive process, cryptocurrencies must incentivize it by offering rewards to miners. +A minimum amount of mining power is required for the cryptocurrency to work. Without new blocks, there can be no new transaction. The more mining power and diversity (different miners), the harder it is to attack the \ac{DLT}. Since mining is an expensive process, cryptocurrencies must incentivize it by offering rewards to miners. Rewards are of two kinds: \begin{itemize} \item \textbf{Coin generation} While mining a block, the miner creates money in it that he can use as he pleases. Bitcoins use this type of reward but to reach a constant amount of 21 million bitcoins, this reward decreases over time. - \item \textbf{Transaction fee} Transactions may contain a tip for the miner to encourage mining. Miners will not mine transactions that cost them money and will mine the most profitable transaction first. Transaction fees are then market-based values, the more transactions that are waiting to be mined, the higher the fee you have to pay to be in the next block. When a transaction is sent with a fee too small, it may not be mined in a timely fashion. Since transaction fees are unpredictable, transactions sometimes end being stuck for a long time. + \item \textbf{Transaction fee} Transactions may contain a tip for the miner to encourage mining. Miners will not mine transactions that cost them money and will mine the most profitable transaction first. Transaction fees are then market-based values, the more transactions there are waiting to be extracted, the higher the fee to be paid to be included in the next block. When a transaction is sent with a fee too small, it may not be mined in a timely fashion. Since transaction fees are unpredictable, transactions sometimes end being stuck for a long time. \end{itemize} \subsection{Blockchain-based cryptocurrencies limitations} @@ -172,6 +172,7 @@ The settlement layer provides finality for wire transfers that allow customers t \begin{figure}[h] \begin{center} + \vspace{0.5em} \input{figures/settlement_layer.tex} \end{center} \caption{DLT settlement layer with Depolymerizer} @@ -194,6 +195,7 @@ Taler expects credits to be final. If a credit disappears from the blockchain, a \begin{figure}[H] \begin{center} + \vspace{0.5em} \input{figures/conf_delay.tex} \end{center} \caption{Reorganization mitigation using confirmation delay} @@ -206,6 +208,7 @@ Using a confirmation delay does not solve the problem, it only mitigates it. We \begin{figure}[H] \begin{center} + \vspace{0.5em} \input{figures/harmless_reorg.tex} \end{center} \caption{Harmless reorganization} @@ -216,6 +219,7 @@ If confirmed credits have been removed, we will suspend operations. If we are no \begin{figure}[H] \begin{center} + \vspace{0.5em} \input{figures/conflict.tex} \end{center} \caption{Reorganization with conflicting transaction} @@ -228,6 +232,7 @@ If we experience a reorganization once, it is dangerously likely that another on \begin{figure}[H] \begin{center} + \vspace{0.5em} \input{figures/analysis.tex} \end{center} \caption{Adaptive confirmation} @@ -460,8 +465,6 @@ Then we chose an aggressive memory budget of 4kB, as all request bodies should b \subsection*{Testing} -% Move testing to its own section - The Taler exchange has a taler-exchange-wire-gateway-client CLI that allowed me to test that my implementation not only conforms to the \ac{API} documentation but also with how the official client handles it. I found confusion in the documentation where it was specified that timestamp should consist of time in milliseconds since epoch, but the client will reject timestamps that are not rounded to second. \clearpage diff --git a/test/btc/analysis.sh b/test/btc/analysis.sh diff --git a/test/btc/bumpfee.sh b/test/btc/bumpfee.sh diff --git a/test/btc/config.sh b/test/btc/config.sh diff --git a/test/btc/conflict.sh b/test/btc/conflict.sh diff --git a/test/btc/hell.sh b/test/btc/hell.sh diff --git a/test/btc/lifetime.sh b/test/btc/lifetime.sh diff --git a/test/btc/maxfee.sh b/test/btc/maxfee.sh diff --git a/test/btc/reconnect.sh b/test/btc/reconnect.sh diff --git a/test/btc/reorg.sh b/test/btc/reorg.sh diff --git a/test/btc/stress.sh b/test/btc/stress.sh diff --git a/test/btc/wire.sh b/test/btc/wire.sh diff --git a/test/conf/bitcoin.conf b/test/conf/bitcoin.conf diff --git a/test/conf/bitcoin2.conf b/test/conf/bitcoin2.conf diff --git a/test/conf/bitcoin_auth0.conf b/test/conf/bitcoin_auth0.conf diff --git a/test/conf/bitcoin_auth1.conf b/test/conf/bitcoin_auth1.conf diff --git a/test/conf/bitcoin_auth2.conf b/test/conf/bitcoin_auth2.conf diff --git a/test/conf/bitcoin_auth3.conf b/test/conf/bitcoin_auth3.conf diff --git a/test/conf/bitcoin_auth4.conf b/test/conf/bitcoin_auth4.conf diff --git a/test/conf/bitcoin_auth5.conf b/test/conf/bitcoin_auth5.conf diff --git a/test/conf/taler_btc.conf b/test/conf/taler_btc.conf diff --git a/test/conf/taler_btc_auth.conf b/test/conf/taler_btc_auth.conf diff --git a/test/conf/taler_btc_bump.conf b/test/conf/taler_btc_bump.conf diff --git a/test/conf/taler_btc_lifetime.conf b/test/conf/taler_btc_lifetime.conf diff --git a/test/conf/taler_eth.conf b/test/conf/taler_eth.conf diff --git a/test/conf/taler_eth_bump.conf b/test/conf/taler_eth_bump.conf diff --git a/test/conf/taler_eth_lifetime.conf b/test/conf/taler_eth_lifetime.conf diff --git a/test/eth/analysis.sh b/test/eth/analysis.sh diff --git a/test/eth/bumpfee.sh b/test/eth/bumpfee.sh diff --git a/test/eth/hell.sh b/test/eth/hell.sh diff --git a/test/eth/lifetime.sh b/test/eth/lifetime.sh diff --git a/test/eth/maxfee.sh b/test/eth/maxfee.sh diff --git a/test/eth/reconnect.sh b/test/eth/reconnect.sh diff --git a/test/eth/reorg.sh b/test/eth/reorg.sh diff --git a/test/eth/stress.sh b/test/eth/stress.sh diff --git a/test/eth/test.sh b/test/eth/test.sh diff --git a/test/eth/wire.sh b/test/eth/wire.sh diff --git a/test/gateway/api.sh b/test/gateway/api.sh diff --git a/test/gateway/auth.sh b/test/gateway/auth.sh diff --git a/wire-gateway/src/main.rs b/wire-gateway/src/main.rs @@ -125,7 +125,7 @@ async fn main() { .iter() .map(|it| match it { Host::Tcp(it) => it.to_string(), - #[cfg(target_os = "linux")] + #[cfg(unix)] Host::Unix(it) => it.to_str().unwrap().to_string(), }) .collect(),