Optionality = the right but not the obligation to take action.
Generating better options is more important thaant beinbg a perffect decision-maker.
We should think of tradeoffs as the enemy: then are massinvely time-cincuming;, and they make ud unhappy… we want to /make asa fee as we can get away with.
So the question if not what to cut. Our starting point is thta everything gets cut, and has to earn its way back into ciniseradriotn,
parser - takes text and builds data structure that represents the input
statements vs. expressions - expressions produce values and statements dont.
lexer - reduces to tokens
ast - abstract syntax tree
https://www.instructables.com/Understanding-how-ECDSA-protects-your-data/
Allows verification of authenticity without compromising security. It is impossible to forge a signature. It does no encrypt the data but ensures it is not tampered with.
Algo (high level)
choose random point on curve, point of origin
generate a random number, private keys
apply equation to private key and point of origin, public key
Sign the file
equation(use the private key, with a hash of the file), signature
signature is divided into R and S
Verification
equation(S, public key) == R
ECDSA uses SHA1 hashes
transaction input and output - there will be a difference between them which is the miner fee
transactions form a chain
users keys can unlock previous output in the chain proving ownership
change address - address of new and old user
UTXO - unspent transactions database
It is called when a non-existent function is called on the contract.
It is required to be marked external.
It has no name.
It has no arguments
It can not return any thing.
It can be defined one per contract.
If not marked payable, it will throw exception if contract receives plain ether without data.
Solidity fallback function:
It has no name, no arguments, no return values. It external and payable. Defined once. Called when non-existent function called.
Externally owned accounts are those that have a private key; having the private key means control over access to funds or contracts.
A contract account has smart contract code, which a simple EOA can’t have. Furthermore, a contract account does not have a private key. Instead, it is owned (and controlled) by the logic of its smart contract code: the software program recorded on the Ethereum blockchain at the contract account’s creation and executed by the EVM.
account addresses are derived directly from private keys: a private key uniquely determines a single Ethereum address, also known as an account.
There is no encryption as part of the Ethereum protocol—all messages that are sent as part of the operation of the Ethereum network can (necessarily) be read by everyone. As such, private keys are only used to create digital signatures for transaction authentication.
Starting with a private key in the form of a randomly generated number k, we multiply it by a predetermined point on the curve called the generator point G to produce another point somewhere else on the curve, which is the corresponding public key K: K = k * G
the generator point is always the same for all Ethereum users
Ethereum only uses uncompressed public keys; therefore the only prefix that is relevant is (hex) 04.
The test most commonly used for a hash function is the empty input. If you run the hash function with an empty string as input you should see the following results:
Keccak256(““) = c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470
SHA3(““) = a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a
Ethereum uses Keccak-256, even though it is often called SHA-3 in the code.
Ethereum addresses are unique identifiers that are derived from public keys or contracts using the Keccak-256 one-way hash function.
We use Keccak-256 to calculate the hash of this public key:
Keccak256(K) = 2a5bc342ed616b5ba5732269001d3f1ef827552ae1114027bd3ecf1f086ba0f9
Then we keep only the last 20 bytes (least significant bytes), which is our Ethereum address:
001d3f1ef827552ae1114027bd3ecf1f086ba0f9
A transaction is a serialized binary message that contains the following data:
Nonce
A sequence number, issued by the originating EOA, used to prevent message replay
Gas price
The amount of ether (in wei) that the originator is willing to pay for each unit of gas
Gas limit
The maximum amount of gas the originator is willing to buy for this transaction
Recipient
The destination Ethereum address
Value
The amount of ether (in wei) to send to the destination
Data
The variable-length binary data payload
v,r,s
The three components of an ECDSA digital signature of the originating EOA
Computer programs
Smart contracts are simply computer programs. The word “contract” has no legal meaning in this context.
Immutable
Once deployed, the code of a smart contract cannot change. Unlike with traditional software, the only way to modify a smart contract is to deploy a new instance.
Deterministic
The outcome of the execution of a smart contract is the same for everyone who runs it, given the context of the transaction that initiated its execution and the state of the Ethereum blockchain at the moment of execution.
EVM context
Smart contracts operate with a very limited execution context. They can access their own state, the context of the transaction that called them, and some information about the most recent blocks.
Decentralized world computer
The EVM runs as a local instance on every Ethereum node, but because all instances of the EVM operate on the same initial state and produce the same final state, the system as a whole operates as a single "world compute
0x0 special contract creation address
contracts only run if they are called by a transaction
contracts are atomic
To delete a contract, you execute an EVM opcode called SELFDESTRUCT. That operation costs “negative gas,” a gas refund, thereby incentivizing the release of network client resources from the deletion of stored state.
function syntax:
function FunctionName([parameters]) {public|private|internal|external} [pure|view|payable] [modifiers] [returns (return types)]
estimating gas cost:
var contract = web3.eth.contract(abi).at(address); var gasEstimate = contract.myAweSomeMethod.estimateGas(arg1, arg2, {from: account});
To obtain the gas price from the network you can use:
var gasPrice = web3.eth.getGasPrice();
And from there you can estimate the gas cost:
var gasCostInEther = web3.utils.fromWei((gasEstimate * gasPrice), ‘ether’);
This type of attack can occur when a contract sends ether to an unknown address. An attacker can carefully construct a contract at an external address that contains malicious code in the fallback function.
The first is to (whenever possible) use the built-in transfer function when sending ether to external contracts.
The second technique is to ensure that all logic that changes state variables happens before ether is sent out of the contract (or any external call).
A third technique is to introduce a mutex.
The current conventional technique to guard against under/overflow vulnerabilities is to use or build mathematical libraries that replace the standard math operators addition, subtraction, and multiplication (division is excluded as it does not cause over/underflows and the EVM reverts on division by 0).
ERC20
The ERC20 Interface in Solidity:
contract ERC20 {
function totalSupply() constant returns (uint theTotalSupply);
function balanceOf(address _owner) constant returns (uint balance);
function transfer(address _to, uint _value) returns (bool success);
function transferFrom(address _from, address _to, uint _value) returns
(bool success);
function approve(address _spender, uint _value) returns (bool success);
function allowance(address _owner, address _spender) constant returns
(uint remaining);
event Transfer(address indexed _from, address indexed _to, uint _value);
event Approval(address indexed _owner, address indexed _spender, uint _value);
}
data structures
mapping(address => uint256) balances;
mapping (address => mapping (address => uint256)) public allowed;
transfer - wallet to wallet direct transfer of tokens, uses the ‘transfer’ function
approve and transfer - two transaction