Decentralized Organizations (DO)

1. Software programs that run on blockchain

2. Added to blockchain in form of smart contracts
3. Once added becomes decentralized
4. Interact based on code defined within DO software
5. Rely on human input to execute business logic

Decentralized Autonomous Organizations (DAO)

1. Runs on top of blockchain
2. Governance and business logic rules are embedded within it
3. Autonomous
4. Fully automated and contain AI logic
5. Code is governing entity
6. Human curator maintains code, proposal evaluator for community
7. Capable of hiring external contractors if enough input is received from token holders -
participants

Decentralized Autonomous Corporations (DAC)

1. Similar to DAO in concept
2. Smaller subset of DAO
3. DAO are non-profit and DAC can earn profit
4. Profit via shares offered to the participants to whom they can pay dividends
5. Run business automatically without human intervention based on logic programmed

Decentralized Autonomous Societies (DAS)

1. Entire society can function on blockchain
2. Multiple complex smart contracts and combination of DAOs and DApps running
autonomously
3. Many services that a govt offers can be delivered via blockchain
4. Government ID card, passport, records of deeds, marriage and births

DApps
1. DAO, DAC, DO and DApps run on blockchain in P2P network
2. Type 1 - Software programs that can run on their respective blockchains - Bitcoin
 3. Type 2 - Use existing established blockchain
4. Type 3 - use only protocols of an existing blockchain

Requirements of a DApp:
1. Fully open source and autonomous
2. No single entity should be in control of majority of tokens
3. All changes must be consensus driven - based on feedback
4. Data and records should be cryptographically secured
5. Data should be stored in public decentralized blockchain (avoid central point of failure)
6. Cryptographic token to provide access and rewards for value contributors (miners in
bitcoin)
7. Token generated by standard cryptographic algorithm - acts as a proof of value to
contributors

Operations of DApp:
1. Establishment of consensus by DApp - PoW and PoS consensus algos
2. PoW - incredibly resistant to 51% attacks
3. Can distribute tokens via mining, fundraising and development

Examples:
1. KYC Chain
2. OpenBazaar
3. Lazooz

Platforms for decentralization:

1. Ethereum
a. First to introduce Turing-complete language - Solidity
b. Concept of VM
c. Contrast to limited scripting lang in bitcoin and many other cryptocurrencies
d. Currency tokens - Ethers
2. Maidsafe
a. Provides Secure Access For Everyone network
b. Make of unused computing resources
 c. Files on network are divided into chunks of data - encrypted and distributed
randomly throughout the network
d. Data can be retried only by respective owner
e. Duplicates are automatically rejected
f. Reduce the need for additional computing resources
g. Token is safecoin
3. Lisk
a. Blockchain app development and crypto platform
b. JavaScript to build decentralized apps and host in side chains respectively
c. Uses Delegated Proof of Stake (DPOS) mechanism for consensus
d. 101 nodes elected to secure network and propose blocks
e. node.js and javascript for backend
f. Html css and javascript for frontend
g. LSK coin as currency
h. Rise is derivative of Lisk - greater focus on security

Smart contracts
1. A smart contract is a secure and unstoppable computer program representing an
agreement that is automatically executable and enforceable.
2. Decentralized program
3. Language in which target machine can understand
4. Not necessarily need blockchain to run
5. Due to security - blockchain has become standard decentralized execution platform for
smart contracts
6. Limited amount of data
7. Some business logic - automatically executed if specific criteria are met
8. Actors or participants use these smart contracts or run behalf of network participants
autonomously
9. Encompasses agreement between parties in form of business logic
10. Enforceable - terms are executed as defined and expected even in the presence of
adversaries

True smart contracts:

1. No need for arbitrary or third part to control influence of execution
 2. Self enforcing - opposed to legally enforceable
3. Secure and unstoppable - fault tolerant and executable in reasonable amount of time
4. Automatable - intervention of human in some scenarios
5. Usually operate by managing their internal state using state machine model
6. Deterministic nature - highly desirable due to consistent consensus requirements
7. LKIF - XML Schema for representing theories and proofs - smart contract code and
natural language contract - contract terms and machine understandable elements

Smart contracts are inherently required to be deterministic - Why?

1. Allow SC to be run by any node on network and achieve same result
2. Consensus cannot be achieve if result differ even slightly
3. It is also desirable that contract language itself is deterministic
4. Ensuring integrity and stability of smart contracts
5. Deterministic - no non-deterministic functions to be used - different results in different
nodes
6. Same output for specific input
7. Programs when executed produce a reliable and accurate business logic - in line with
requirements programmed in high level code
8. Four properties
a. Automatically executable
b. Enforceable
c. Semantically sound
d. Secure and unstoppable
Ethereum Virtual Machine
1. Simple stack based execution machine
2. Runs bytecode instructions for system state transformation
3. Word size - 256 bit
4. Big-endian by design
5. Allow Keccak 256-bit and ECC computations
6. Stack size 1024 elements
7. LIFO queue
8. Turing complete machine - limited by amount of gas that is required to run any
instruction
 9. Infinite loops can result in Denial of Service attacks are not possible due to gas
requirements
10. Supports exceptional handling
11. Entirely isolated and sandboxed runtime environment
12. Code does not have access to any external resources like network or FS
13. Increased security, deterministic execution and allow untrusted code (anyone can run)
14. Two types of storage for contracts and EVM:
a. Memory - byte array - memory is cleared once code execution is complete - RAM
b. Storage - permanently stored on blockchain - key, value store - hard disk
15. Memory is unlimited but constrained by gas fee requirements
16. Storage - word addressable word array - nonvolatile - maintained part of system state
17. Key value are 32 bytes
18. Program code is stored in virtual ROM - accessible using codecopy instruction - copy
code to main memory
19. Initial all storage and memory are set to 0 in EVM

Issues in Solidity language

10 issues - with examples:
1. Unchecked External Call
a. Do not throw an exception
b. Instead return false
c. Low-level call methods like address.call()
2. Costly Loops
a. Computational power is paid through Ether
b. Reducing computational steps - cost efficiency rather than optimization
c. Loops are costly operations - infinite loops exhaust all gas

d.
3. Overpowered Owner
a. Some contracts tightly coupled to owner
 b. Some functions callable only by owner address (onlyOwner modifier or
msg.sender == owner)
c. If private key is compromised attacker can gain control over contract

d.
4. Arithmetic Precision
a. Data types are cumbersome due to 256 bit EVM
b. Does not offer a floating point representation
c. Data types shorter than 32 bytes are packed into same 32 bytes slot
d. Precision issues - huge rounding issues while dividing

e.
5. Relying on tx.origin
a. Contracts should not rely on tx.origin for authentication
b. Malicious contract may play in middle draining all funds
c. Msg.sender should be used instead

d.
6. Overflow/Underflow
a. 256 bits - brought back overflow underflow issues
b. Be extra careful while using uint data types in for-loop - may result in infinite loop
 c.
7. Unsafe type inference
a. Smallest integer type sufficient to store right hand side value (uint8)
b. If elements has more than 256 elements - overflow
c. Explicitly declaring data types is recommended to avoid unexpected behavior
and/or errors

d.
8. Improper Transfer
a. More than one way to transfer Ether between contracts
b. addr.transfer(x) function is the recommended way - throws an exception if
transfer is unsuccessful, mitigate unchecked external call issues
c. But contracts use send() instead

d.
9. In-Loop transfers
a. If Ether is transferred in a loop, if one of the contracts cannot receive it, then
whole transaction is reverted
b. Attacker may take advantage of this to cause DoS preventing other contracts to
receive Ether

c.
10. Timestamp dependence
a. Smart contracts run on multiple nodes on a different time
b. EVM does not provide clock time
c. ‘now’ variable is used to obtain timestamp - environment variable
(block.timestamp) - miners can manipulate
 d. Since miners can manipulate, environment variables should be used in
inequalities only

e.

Execution environment of EVM

1. Key parameters are provided by execution agent

2.

Machine state
1. Maintained internally by EVM
2. Updated after each execution cycle of EVM
3. Iterator runs in VM - outputs results of single cycle of state machine
4. (available gas, program counter (upto 256), stack content, active number of words in
memory, stack content)
5. Throws exception if
a. Not enough gas
b. Invalid stack size
c. Insufficient stack items
d. Invalid destination of jump opcodes
Iterator function
1. Performs various vital functions
2. Set next state of machine - eventually the world state
3. Fetch next instruction from byte array - machine code is stored
4. Add or remove items from stack
5. Gas is reduced according to gas cost
6. Increments PC

7.