Before the year 1944 most countries followed the gold standard, each country guaranteed that it would redeem its currency for its value in gold. A countries currency could was based on a fixed quantity of gold.
In 1944 the Bretton Woods Conference was held in the US, at this conference they decided that the US dollar will be the core of the new international money system, mainly because of US political and economical stability. This system provided better mechanisms for international trade such as fixed exchange rates.
This system pegged the US dollar to gold, 1 ounce of gold was equal to US$35.00. All other currencies (except for the USD) had a fixed exchange rate to the dollar (The central banks could also adjust the rate). Basically it meant that for every USD in circulation there was and ounce of gold stored somewhere, through various trading partners you could directly exchange the 35.00 USD to an ounce of gold. This gave the USD value and all other currencies that where anchored to it value. But unlike the older gold standard individuals could not trade their money to gold using local banks.
For a while the system was operating smoothly, creating economies that where not effected by inflation, allowing for economical growth.
By the 1960 the number of USD in circulation was more then the Gold in the treasury (at Fort Knox), the main reason is attributed to USA’s spending on the Vietnam War. This further caused the confidence in the system and America’s leadership to dwindle.
In 1971 President Nixon effectively ended the Bretton Woods System.
Most countries today use paper fiat money (“Faith based money”), which is money that lacks intrinsic value, it’s value is based on supply and demand (marketplace). The government must protect fiat against counterfeiting and manage the money supply(Fiscal Policy) responsibly.
Advantages
Disadvantages
Fiat money has generally seen much higher inflation and higher levels of debt. Because of these two forces consumer prices increase and the central banks raise interest rates.
If the a. government struggled to afford its interest payments, foreign creditors could dump the currency and trigger a collapse.
Digital cash systems are prone to double-spending which is a flaw that allows the same digital token to be spend more then once. Digital tokens exist as a digital file (a string of bits) that can be duplicated. Double-spending leads to inflation which devalues the currency.
There are two forms of digital currencies, centralized which involves trusted 3rd party institutions and decentralized which is generally peer-to-peer.
It is easier to prevent double-spending attacks in a centralized system because all the state of the network (who has what coin) is stored in one place (the trusted 3rd party) and this is one of the reasons traditional commerce on the internet is centralized.
It is much more difficult to prevent double-spending attacks in decentralized systems, due to the nature of distributed systems, for example if we a have a naive system that has three peers A, B and C. Let’s assume peer A has a single token x and wants to send it to B:
A[x] -> Bafter this everyone in our decentralized network should have the same state, in other words all peers should be able to verify that A no longer has the x token because he transferred it to B. But in our naive network allot can go wrong maybe C was offline when the transaction (A[x] -> B) took place or maybe C has a slower internet connection this causes the state of the network to be unsynchronized between the peers in our network (C has old state while A and B have updated state) this means that A can transfer the same token (x) to peer C and this is a double-spend.
The above example illustrates how difficult it is to prevent double-spending in decentralized system, they have to include a consensus mechanism to prevent double spending.
A common problem that arises in payment systems is the reversibility of transactions.
For reversibility to be possible in any payment system trust of a 3rd party is needed to arbitrate the transaction of the two parties involved. The buyer and seller should trust that the trusted 3rd party will make the correct decision (reverse or not reverse the transaction) based on the policies and rules of the system.
The ability to reverse transactions has some advantages but it also has it’s own set of disadvantages.
Trust based systems are centralized around the 3rd party arbitrator whilst in decentralized Peer to Peer systems where no 3rd party is present there is no one to trust this is why in decentralized systems reversible transactions are usually not possible by design. In decentralized systems only the underlying cryptography of the system is trusted, this approach is much more secure, faster and affordable because:
Irreversibility also means that the ledger is a single persistent structure with an immutable history this makes allot of sense philosophically and practically.
How do you get money, you get money by giving away something of value. Value is price, and it is decided by supply and demand aka the market. Money is a system to exchange value, but why do we have to exchange value, why can we not give away something of value without getting something in return. This might be a feature/flaw in nature or simply a conditioning, but because of this we have systems to exchange value.
Governments are described in terms of economic systems, value exchange is a fundamental protocol of society it surpasses language, religion, race in its influence in our day to day living…
What mechanisms do decentralized protocls offer? Let us try to find out!
When I play a game I want to know all of the features of the character I am controlling, I want to know what every button is for and how to combine these buttons and see what magic I can create. This is how I like my protocls, I want to know the kinds of applications I can build using these abstract rules.
The mechanisms in networking protocls can be divided in to two categories:
- User Mechanisms
- Developer MechanismsHowever in any protocol both users and developers require some obvious mechanisms:
- Send
- Receive
- ConnectionWe can have a protocol that has one mechanism for the user: send data. We can also have a protocol has one mechanism for the user: receive data. But we cannot have protocols that don’t offer any of those two axiomatic mechanisms (same rules apply to developers). Imagine having a protocol that allows the user to store data offline but it does not give the user the mechanism of receiving data, it is impossible.
We can already build allot from those two mechanisms but only within the bounds of the protocol. For example we can build an app that receives an element’s atomic number and replies with the elements name:
A.send["60"]
B.receive[60]
B.send["Neodymium"]
A.receive["Neodymium"] Here we do not care how B computes the reply, we only care about how A and B interact with each other.
All interactive programs provide two basic functions: obtaining user input and displaying the results. Web applications implement this behavior using two HTTP methods: POST and GET respectively. This simple protocol gets broken when application returns web page in response to POST request. Peculiarities of POST method combined with idiosyncrasies of different browsers often lead to unpleasant user experience and may produce incorrect state of server application. This article shows how to design a well-behaved web application using redirection.
Michael Jouravlev, Redirect After Post Double Submit problem
How does one varify the order of events in a distributed network without a trusted 3rd party?
Bitcoin does this with the proof of work algorithm, it looks at all the events as stated by the peers in the network and chooses the peer with longest stream of events as the most propably valid one. This only works if more then 50% of the peers are honest.
New events are published as blocks, which are a list of transactions within the network. These blocks also link to past blocks (events/transactions) via a hash function. The bitcoin network sets a target (a random 256-bit number), all valid blocks must have a hash below this target. The target is not fixed it changes after every 2016 blocks based on the time it took to discover 2016 previous blocks. If we take a long time to find 2016 blocks then the difficulty is lowered if we discover 2016 blocks very quickly difficulty is increased.
Difficulty formula:
difficulty = target / current_targetThe EVM is a distributed finite state machine that runs on Peer to Peer connected computers, each peer runs the Ethereum client software. Because the EVM is a state machine it allows computations to be performed on it, these computations change the state of the EVM as new blocks are added to the blockchain. The EVM defines the rules for changing its state similar to how the Intel 8086 microprocessor defines the rules to program it’s state with x86 Assembly. The EVM uses a set of 140 unique opcodes which allow it to be Turing-complete.
Computations in the EVM are requested by the users, these computations are not free. Users have to pay ETH to have their computations executed. ETH (ether) is the native cryptocurrency of Ethereum.
Ethereum has two types of accounts, namely Externally Owned Accounts (EOA) and Contract Accounts. Asymmetric cryptography is used to secure and control EOAs, peers in the Ethereum network use EOAs to store Ether. Contract Accounts are basically EVM instructions also known as smart contracts. Accounts and their balances are stored in a big table in the EVM, they are a part of the EVM state.
// Pseudo Account (Rust code)
struct Account{
/// Account nonce
pub nonce: u256,
/// Account balance
pub balance: u256,
/// Account storage
pub storage: BTreeMap<H256, H256>,
/// Account code (Hash)
pub code: Vec<u8>
}In the Ethereum world a decentralized application is known as a Dapp. The Ethereum documentation [0] attributes the following properties to Dapps:
To create Dapps developers need to write smart contracts using the Solidity Programming Language (https://en.wikipedia.org/wiki/Solidity), smart contracts are deployed on the EVM and cannot be changed afterwards. Because they run on the EVM which is p2p and not a traditional client-server setup Dapps are decentralized.
A Ethereum transaction is a cryptographically signed instruction from an externally owned account, it instructs the EVM to change it’s state. Ethereum miners are responsible for the actual execution of the transaction, miners charge a fee for this execution and after the execution is complete they propagate the new EVM state to entire Ethereum network. Gas is the unit used to measure the computational work required to execute specific instructions. The gasLimit and gasPrice determine the maximum transaction fee paid to a miner for executing instructions. If the recipient of the transactions is an externally-owned account, the transaction will transfer value, if the recipient is a contract account, the transaction will execute the contract code.
// Pseudo Transaction (Rust code)
struct Transaction{
/// The receiving address
/// H160 is a Fixed-size uninterpreted hash type with 20 bytes (160 bits) size
recipient: H160,
/// The identifier of the sender, generated by the sender's private key.
signature: H160,
/// Amount of ETH to transfer from sender to recipient
amount: U256,
/// Optional field to include arbitrary data
data: Vec<u8>,
/// The maximum amount of gas units that can be consumed by the transaction.
/// Units of gas represent computational steps.
gasLimit: usize,
/// The fee the sender pays per unit of gas
gasPrice: U256
}
Once a user submits a transaction, it is first broadcasted to the network and then included in a transaction pool that contains other submitted transactions by different peers in the Ethereum network. Miners are always on the lookout for transactions, and select them from the mining pool based on the gasPrice because it they want to make a profit. If a transaction’s gasPrice is low it might take a long time for it to be selected and executed by a miner.
Once a transaction has been submitted and executed it is stored inside a block together with other transactions that have been executed around the same time. A block also contains a hash of the previous block in the chain. Because each block in the chain is linked to a previous block (except for the genesis block) this means that the blockchain is a temper proof log of past transactions, if an malicious user tries to change the history of events (who owns what transaction) then the entire chain collapses because all the hashes will become invalid.
Because of how the Ethereum blockchain is structured the user cannot immediately feel confident that the transaction has been received on the other side by the intended receiver this can be because of network delays, network forks etc. Blockchain confirmations allow a user to know with some amount of certainty (though never 100%) that the transaction has went through.
A Confirmation is the number of times another block is placed after the block that contains the user’s transaction. Blockchain Confirmations are a measure of security, every block that is added after the user’s transaction gives the user confident that transaction is much less likely to be reversed and is therefore more secure. The larger the block confirmation number the more immutable the transaction is. So for higher value transactions, more block confirmations may be desired.
To use use Ethereum a user should be running client software. Ethereum supports 3 types of Nodes:
- Stores full blockchain data.
- Participates in block validation, verifies all blocks and states.
- All states can be derived from a full node.
- Serves the network and provides data on request
In Ethereum, a light client can be viewed as a client that downloads block headers by default, and verifies only a small portion of what needs to be verified, using a distributed hash table as a database for trie nodes in place of its local hard drive.
- Stores everything kept in the full node and builds an archive of historical states. Needed if you want to query something like an account balance at block #4,000,000.
- These data represent units of terabytes which makes archive nodes less attractive for average users but can be handy for services like block explorers, wallet vendors, and chain analytics.
Tokens are digital assets that run on Ethereum, tokens can represent anything depending on the application. For example tokens can be deployed to represent votes, financial asset bonds, poker chips etc etc.
ERC-20 (Ethereum Request for Comments 20) is an Ethereum standard that specifies a type of fungible token (tokens that are the same in value and type). ERC-20 tokens run within smart contracts.
If a Smart Contract implements the following methods and events it can be called an ERC-20 Token Contract and, once deployed, it will be responsible to keep track of the created tokens on Ethereum.
// ERC-20 Methods
// Javascript code, Shamelessly borrowed from
// https://ethereum.org/en/developers/docs/standards/tokens/erc-20/
function name() public view returns (string)
function symbol() public view returns (string)
function decimals() public view returns (uint8)
function totalSupply() public view returns (uint256)
function balanceOf(address _owner) public view returns (uint256 balance)
function transfer(address _to, uint256 _value) public returns (bool success)
function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)
function approve(address _spender, uint256 _value) public returns (bool success)
function allowance(address _owner, address _spender) public view returns (uint256 remaining)
// ERC-20 Events
// Shamelessly borrowed from
// https://ethereum.org/en/developers/docs/standards/tokens/erc-20/
event Transfer(address indexed _from, address indexed _to, uint256 _value)
event Approval(address indexed _owner, address indexed _spender, uint256 _value)Ethereum also supports non-fungible tokens, visit this link to learn more about them.
[home] | Emancipation through technology |
