1. OTHER THOUGHTS
1.1. For large companies, the blockchain presented itself as a headache initially. It was something they had not planned for.
1.2. DApps are not free for use. This is one of the places where centralized applications get the upper hand as centralized applications can be monetized using ads, providing premium APIs for third-party apps, and so and can be made free for users.
1.3. The blockchain enables user anonymity by choice, and it is one of the most annoying features for regulators and financial reporting authorities, specifically in consumer applications
1.4. In this new world of decentralized technologies, security, privacy, and data ownership requirements are part of the design and not an afterthought.
1.5. Decentralized app paradigm, don't mix up with clustering
1.6. Fotrune cookie principle blockchain suffers from
1.6.1. Every idea, innovation, product and service has two elements. The cookie…. the commodity, the utility, the tangible, the facts, the logical benefit. The cookie is the thing you put in the shop window which has a fixed inherent value. Then there’s the fortune, the intangible part of the product or service which is where the real value lies. The fortune is the abstract, the thing that changes how people feel. The real reason they buy the product in the first place. It’s your story and purpose, your vision and values manifested. The fortune gives the product an acquired value or a different perceived value. People don’t buy fortune cookies because they taste better than every other cookie on the shelf. They buy them for the delight they deliver at the end of a meal.
1.6.2. For developers, the blockchain has meaning. They have found the fortune story inside, before eating the cookie. But for the general public of users and many enterprises, Bitcoin, blockchains or cryptocurrencies do not have a lot a meaning (yet), because they are being sold the cookie. Engineers typically want to solve a technical problem. But if solving the technical problem does not result in solving an end-user problem, users will ask: “Was that a solution looking for a problem…because I do not see this problem.”
2. PROBLEMS
2.1. But blockchains are not perfect. They also introduce security challenges due to their inherent designs relating to three key areas: Consensus engines on blockchains Decentralization of computing architectures Peer-to-peer clients Consensus in public blockchains is done publicly, and is theoretically subject to the proverbial Sybil attacks (although it has not happened yet). The trend for decentralized computing architectures requires a new mindset for planning and writing applications that is different than the traditional Web architectures. . We also need to be aware that Internet of Things devices also are subject to potential security breaches, because potential vulnerabilities are being pushed from the centers to the edges, wherever there is some computing resources at the edge. Luckily, some solutions are in the works, such as private blockchains, zero-knowledge proofs and ring signatures.
3. BENEFITS AND INDIRECT BENEFITS
3.1. Outcomes: profits and growth.
3.2. Cost savings: direct or indirect.
3.3. Speed: removing time delays.
3.4. Transparency: providing the right information to the right people.
3.5. Better privacy: protecting consumers, businesses via more granular controls.
3.6. Lower risk: better visibility, less exposure, less fraud, less tampering.
3.7. Access: more equitable access.
3.8. Productivity: more work output.
3.9. Efficiency: faster processing or reporting.
3.10. Quality: less errors or more satisfaction.
4. Proof piramide
4.1. http://techbus.safaribooksonline.com/getfile?item=c3IwczczMTFhLzlkMS9tcDlnL2llY3N0ODExMDNhc2dwZmUxamUwMGcvMnNtL2F0Y2kwLg--
5. What blockchain enables? Where to use it
5.1. Assets, Trust, Ownership, Money, Identity, Contracts Indeed, the blockchain offers: Programmable Assets Programmable Trust Programmable Ownership Programmable Money Programmable Identity Programmable Contracts Put together, these six concepts are powerful catalysts for understanding where the blockchain can be used in any particular situation. Let us expand on some of these topics. Creation and Real-Time Movement of Digital Assets Digital assets can be created, managed, and transferred on a blockchain network without incurring clearing-related delays due to the existence of intermediaries. Not requiring human or central database intervention to enforce verifiability is a fundamental novelty. Embedding Trust Rules Inside Transactions & Interactions By inserting rules that represent trust inside transactions, the blockchain becomes a new way to validate these transactions via logic in the network, not via a database entry or central authority. Therefore, a new “trust factor” is created that is part of the transaction itself. Time-Stamping, Rights, & Ownership Proofs The blockchain allows the time-stamping of documents representing rights or ownerships, therefore providing irrefutable proofs that are cryptographically secure. This, in turn, can enable a variety of applications to be built on top of these new seamless verification capabilities. Self-Execution of Business Logic with Self-Enforcement Because verification is done by the blockchain’s black box, and the trust component is part of the transaction, the end-result is a self-clearing transaction. The clearing and settlement of assets are merged together. Selective Transparency & Privacy This is achieved via cryptographic technologies, and it will result in new levels of decentralized data privacy and security where transactions can be verified without revealing everything about the identity of their owners. Transparency exposes the ethics of a business, so it will get resisted. But increased transparency can also provide increased levels of trust. Resistance to Single Points of Failure or Censorship Because the blockchain consists of several decentralized computers and resources, there is no single point of failure; therefore, the network is more resilient than centrally controlled infrastructures. Blockchains are typically censorship resistant, due to the decentralized nature of data storage, encryption, and peer controls at the edge of the network.
6. Identity management and representation
6.1. In the blockchain world, there are various approaches that are addressing identity and personal security, including granting us access to data and services. Some require new hardware solutions, others are software-based, and some integrate with business-to-business solutions. Hardware. The analogy is similar to showing a passport, or other government-issued identity card, such as a driver’s license. That card gives us access to travel, or authorizes us to drive a car. On the blockchain, some of these solutions are also combining biometric data to add to the authentication mix. Examples: ShoCard, Case. Software. The closest analogy is the current OAuth-based identifications we routinely perform on the Web when signing into websites using our Facebook, Twitter or Google IDs. But with blockchain solutions, the roles are reversed: you self-register your identity first, and then you link to your social accounts. Examples: Netki, OneName, BitID, Identifi. Integration-first. Whereas the first two approaches generally start with the consumer, this segment starts by figuring out the integration requirements with existing business solutions. Examples: Cambridge Blockchain, Trunomi, uPort, Tradle, Ripple KYC Gateway. Blockchain identification schemes have a chance, but there are uncertainties ahead. On the consumer side, could they replace our linking to Facebook, Google, or Twitter, and lure us to start with them instead? And on the business side, could they supplant already entrenched solutions such as SWIFT’s 3SKey multi-bank, multi-network personal identity solution, or Markit’s KYC?
7. What is blockchain? How to think of it from technical, business and legal definitions?
7.1. Tech trend (we don't afraid of new ideas, we are worried about old ones)
7.1.1. blockchain is simply part of the continuation of the history of Internet technology
7.1.2. By mid-2016, 47% of the world’s 7.4 billion population had an Internet connection. In 1995, that number was less than 1%.
7.1.3. As for websites, in 2016, their total number hovered at around one billion. Soon blockchain will become as easily configurable as launching a website on Wordpress. (build wind milles not walls)
7.2. Blockchain capabilities
7.2.1. Technical
7.2.1.1. Back-end database that maintains a distributed ledger, openly.
7.2.2. Business
7.2.2.1. Exchange network for moving value between peers.
7.2.3. Legal
7.2.3.1. A transaction validation mechanism, not requiring intermediary assistance.
7.3. How to think about it?
7.3.1. 1) Blockchain new protocol that sits on top of the Internet(connected machines), just as the World Wide Web sits on top of the Internet via its own technology standards (TCP/IP, HTTP, SMTP, OSI model).
7.3.2. 2) 1) game theory, 2) cryptography science, and 3) software engineering
7.3.2.1. The Byzantine Generals Problem - Microsoft Research
7.3.2.1.1. Solving that problem consists in mitigating any attempts by a small number of unethical Generals who would otherwise become traitors, and lie about coordinating their attack to guarantee victory. This is accomplished by enforcing a process for verifying the work that was put into crafting these messages, and time-limiting the requirement for seeing untampered messages in order to ensure their validity. Implementing a “Byzantine Fault Tolerance” is important because it starts with the assumption that you cannot trust anyone, and yet it delivers assurance that the transaction has traveled and arrived safely based on trusting the network during its journey, while surviving potential attacks.
7.4. Blockchain brings
7.4.1. Decentralisation of trust
7.4.2. value flow without intermediates
7.5. Technically it is a state machine
7.5.1. State machine
7.5.1.1. In technical terms, a state just means “stored information” at a specific point in time. A state machine is a computer or device that remembers the status of something at a given instant in time. Based on some inputs, that status might change, and it provides a resulting output for these implemented changes. Keeping track of transitions of these states is important and that’s what the blockchain does well, and in a way that is immutable. In contrast, a database’s record is mutable, because it can be re-written many times over. Not all databases have audit trails, and even if they do, an audit trail could be destroyed or lost, because it is not tamper proof. In the blockchain, the transition history is a persistent part of the information about that state. In the Ethereum blockchain, a distinct “state tree” is stored, representing the current balance of each address, and a “transaction list” representing the transactions between the current block and previous blocks in each block. State machines are a good fit for implementing distributed systems that have to be fault-tolerant.
7.6. Database VS ledger
7.6.1. database is different from a ledger. In a ledger, we can only append new transactions, whereas in a database, we can append, modify, and delete transactions. A database can be used to implement a ledger.
7.7. “If you cannot understand it without an explanation, you cannot understand it with an explanation.” –HARUKI MURAKAMI
7.7.1. Blockchains will enable other products that you will use, while you may not know there is a blockchain behind them, just as you do not know the complexities behind what you are currently accessing on the Web.
7.7.2. There is a belief that the knowledge transfer behind understanding the blockchain is easier than the knowledge about knowing where it will fit (like driving car)
7.8. thougths
7.8.1. A “hash” is a unique fingerprint. Private and public key. Sender uses public to encrypt, receiver uses private to decrypt. Песчинка - отдельная планета с песчинками.
7.8.2. Is a meta technology because it affects other technologies, and it is made up of several technologies itself.
7.8.3. So what is changed - The blockchain is changing how we write applications via a new form of scripting languages that can program business logic as smart contracts that are enforced on the blockchain.
7.9. Blockchain ten props
7.9.1. Digital cryptocurrency
7.9.1.1. Cryptocurrency can have a “production” role for compensating miners who win rewards when they successfully validate transactions. Cryptocurrency can also have a “consumption” role when paying a small fee for running a smart contract (e.g., Ethereum’s ETH), or as a transaction fee equivalent (e.g., Ripple’s XRP or Bitcoin’s BTC). It is hightly volitile and as fiat can be traded.
7.9.2. Decentralised computing infrastructure
7.9.2.1. The blockchain can also be seen as a software design approach that binds a number of computers together that commonly obey the same “consensus” process for releasing or recording what information they hold, and where all related interactions are verified by cryptography. From a physical perspective, networked computer servers are what really powers blockchains. But developers do not need to set up these servers, and that is part of the magic of a blockchain. As contrasted with the Web where an HTTP (Hypertext Transfer Protocol) request is sent to the server, with blockchain apps, the network makes a request to the blockchain.
7.9.3. TX platform
7.9.3.1. Every time a consensus is reached, a transaction is recorded on a “block” which is a storage space
7.9.3.1.1. If we are to equate blockchains to other transactions processing networks, what comes to mind is their processing throughput, which is measured in transactions per second (TPS). As a reference, in 2015, VISA handled an average of 2,000 TPS on their VisaNet, with a peak rate of 4,000 TPS, and a peak capacity of 56,000 TPS. During 2015, PayPal processed a total 4.9 billion payments,7 equivalent to 155 TPS. As of 2016, the Bitcoin blockchain was far from these numbers, hovering at 5–7 TPS, but with prospects of largely exceeding it due to advances in sidechain technology and expected increases in the Bitcoin block size. Some other blockchains are faster than Bitcoin’s. For example, Ethereum started with 10 TPS in 2015, edging towards 50–100 TPS in 2017, and targeting 50,000–100,000 TPS by 2019.8 Private blockchains are even faster because they have less security requirements, and we are seeing 1,000–10,000 TPS in 2016, going up to 2,000–15,000 TPS in 2017, and potentially an unlimited ceiling beyond 2019. Finally, linking blockchain’s output to clustered database technology might push these transactional throughput limits even higher, leading to a positive development.
7.9.4. Shared, distibuted, open ledger
7.9.4.1. The blockchain is also a distributed, public, time-stamped asset ledger that keeps track of every transaction ever processed on its network, allowing a user’s computer to verify the validity of each transaction such that there can never be any double-counting.
7.9.5. Software Development Platform
7.9.6. Open Source Software (Bitcoin core protocol open source) let's grow community
7.9.7. Financial Services Marketplace
7.9.7.1. Derivatives, options, swaps, synthetic instruments, investments, loans, and many other traditional instruments will have their cryptocurrency version, therefore creating a new financial services trading marketplace.
7.9.8. Peer-to-Peer Network
7.9.9. Trust Services Layer
7.9.9.1. All blockchains commonly hold trust as an atomic unit of service. In essence, it is a function and a service that is delivered. But trust does not apply only to transactions. It is extended to data, services, processes, identity, business logic, terms of an agreement, or physical objects. It applies to almost anything that can be digitized as a (smart) asset with an inherent or related value attached to it.
7.10. Blockchain basic functions
7.10.1. Smart property
7.10.1.1. A digital asset is a digitized version of a product that includes specific rights to use, and typically has a value attached to it. Without rights, it is not considered to be an asset, and is just a “digital file.”
7.10.1.2. Smart property takes the concept of a digital asset further, and it links the asset to a blockchain such that it can never be double-spent, double-owned or double-sent. And it’s all within your own control, not someone else’s
7.10.2. Timestamping
7.10.2.1. Timestamping is a basic function that permanently registers on the blockchain the time that a particular action took place. For example, this could be the recording of an asset’s change of ownership, or the fact that an action occurred, like a medical exam or a specific transaction. This is useful to prove or verify at a later date that an event actually took place at that particular time. Timestamping is an irrefutable and immutable action once recorded on a blockchain, so it is useful when seeking the truth.
7.10.3. Multisignature transactions
7.10.3.1. Multisignature (also known as multisig) is a process where more than one signature is required to clear the status of a transaction or to give the go-ahead for an approval. It is the equivalent of requiring multiple signatures on a paper agreement to make it valid, but this happens automatically and quickly on the blockchain. What makes this approach even more powerful is that you can insert business logic in-between the multiple signatures, so that each signature can trigger a new action, resulting in the creation of escrow services as part of these transactions.
7.10.4. Smart contracts
7.10.4.1. Smart contracts promise to program our world on the head of blockchains, and potentially replace some of the functions currently executed by expensive or slow, legacy intermediaries.
7.10.4.2. Smart contracts are not the same as a contractual agreement. If we stick to Nick Szabo’s(1994) original idea, smart contracts help make the breach of an agreement expensive because they control a real-world valuable property via “digital means.” So, a smart contract can enforce a functional implementation of a particular requirement, and can show proof that certain conditions were met or not met. These can be fairly strict implementations, for example, if a car payment is not made on-time, the car gets digitally locked until the payment is received.
7.10.4.3. Smart contracts are not law. Smart contracts, being computer programs, are just the enabling technology, but the consequence of their actions can be made part of a legal agreement, for example a smart contract could transfer shares ownerships from one party to another. As of 2016, the full legal ramifications around smart contracts were a work in progress. A smart contract outcome could be used as an audit trail to prove if terms of legal agreement were followed or not.
7.10.4.4. Smart contracts do not include Artificial Intelligence. Smart contracts are software code representing business logic that runs a blockchain, and they are triggered by some external data that lets them modify some other data. They are closer to an event-driven construct, more than artificial intelligence.
7.10.4.5. Smart contracts are not the same as blockchain applications. Smart contracts are usually part of a decentralized (blockchain) application. There could be several contracts to a specific application. For example, if certain conditions in a smart contract are met, then the program is allowed to update a database.
7.10.4.6. Smart contracts are fairly easy to program. Writing a simple contract is easy, especially if you are using a specific smart contract language (e.g., Ethereum’s Solidity), which lets you write complex processes in a few lines of code. But there are more advanced implementations of smart contracts that use “oracles.” Oracles are data sources that send actionable information to smart contracts. (THIS IS WHAT WE SHOULD PROBABLY DO AN EDUCATE)
7.10.4.7. !!!Create - The next generation of smart contracts will include user-friendly entry points, like a Web browser. That will allow any business user to configure smart contracts via a graphical user interface, or perhaps a text-based language input.
7.10.4.8. Smart contracts are safe. Even in the Ethereum implementation, smart contracts run as quasi-Turing complete programs. This means there is finality in their execution, and they do not risk looping infinitely
7.10.4.9. They apply to almost anything that changes its state over time, and could have a value attached to it.
7.10.5. Smart Oracles
7.10.5.1. Think of them as off-chain data sources that a smart contract can use to modify its behavior. Smart oracles contain a real-world representation of information, such as an identity, an address, or a certificate. They work together in harmony because one of them is on the blockchain (smart contracts), and the other one is off-chain (smart oracles). For example, a smart contract that concerns itself with a Know Your Customer (KYC) function could interact with a smart oracle that contains identity information. Or, if a police officer wishes to check the status of a driver’s license, instead of dialing the motor vehicle database, they could check the blockchain and get the latest information pertaining to the validity of the license, its expiry, or other driver-related information. Conceivably, instead of maintaining expensive central databases, the motor vehicle department could become a smart oracle and publish their data on the blockchain. The data would be encrypted, and only accessible to authorities that hold the right keys to access them, but the process would be more efficient and less costly to maintain
7.10.5.2. Ethereum, for the smart contracts to access centralized APIs, they can use the Oraclize service as a middleman as smart contracts cannot make direct HTTP requests. Oraclize provides a TLSNotary proof for the data it fetches for the smart contract from centralized services.
8. OBSTACLES, CHALLENGES, & MENTAL BLOCKS
8.1. Story about ring
8.2. Catalyst-Barrier-Solution framework perspective http://techbus.safaribooksonline.com/getfile?item=c3IwczczMTFhLzlkMS9tcDlnL2llY3N0ODExMDNhc2dwZmUxamUwMGcvM3NtL2F0Y2kwLg--
8.2.1. Challenges
8.2.1.1. Technical
8.2.1.1.1. Underdeveloped ecosystem infrastructure Lack of mature applications Scarcity in developers Immature middleware and tools Scalability Legacy systems Tradeoffs with databases Privacy Security Lack of standards
8.2.1.2. Market/Business
8.2.1.2.1. Moving assets to the blockchain Quality of project ideas Critical mass of users Quality of startups Venture capital Volatility of cryptocurrency Onboarding new users Few poster applications companies Not enough qualified individuals Costs issues Innovators dilemma
8.2.1.3. Behavioural/Educational
8.2.1.3.1. Lack of understanding of potential value Limited executive vision Change management Trusting a network Few best practices Low usability factor
8.2.1.4. Legal\Regulatory
8.2.1.4.1. Unclear regulations Government interferences Compliance requirements Hype Taxation and reporting
8.3. Progress happens when business drivers are strong, when technology enablers are ready, and when solutions to challenges are found.
9. IMPLEMENTING BLOCKCHAIN TECH
9.1. Most of the major blockchain platforms have been developed via a transparent, open source, collaborative approach, including a good degree of decentralized contributed work.
9.2. levels of sophistication in writing decentralized applications
9.2.1. Use cryptocurrency as a currency unit to pay for services.
9.2.2. Use a blockchain service as a feature, for example, to register an asset or verify the authenticity of a process, typically done via an API.
9.2.3. Use a smart contract on a blockchain to run some business logic that returns a particular value if certain conditions are met, for example, financial derivatives. In this case, there’s a digital asset whose ownership and movement are governed by the blockchain.
9.2.4. Use the blockchain in a more fundamental way, where the app would not function without the blockchain. Typically, you would set-up a specific peer-to-peer network with nodes, for example, OpenBazaar, as a decentralized e-commerce app.
9.2.5. Use your own blockchain (could be shared with others), without an economic token or currency unit. This is where most of the permissioned blockchains play within enterprises.
9.2.6. Use your own blockchain (or another blockchain), including a token or currency unit, to create an economic network of value, for example, MaidSafe,3 which creates a market for unused computing resources over a peer-to-peer network of users.
9.3. 12 features of blockchain platform. Evaluation of a given blockchain platform, the following features are important:
9.3.1. Programmability. What specific programming languages are available?
9.3.2. Upgradability. What is the track record of the developers for delivering enhancements and upgrades to the blockchain?
9.3.3. Transactions manageability. Is there real-time transparency for all transactions?
9.3.4. Affordability. What is the cost of deploying that technology?
9.3.5. Security. What is the documented confidence level in the blockchain’s security?
9.3.6. Speed/Performance. What are the upper limits for speed in validating transactions?
9.3.7. High Availability. What is the uptime’s track record?
9.3.8. Visibility. Do you have a full view on the blockchain activity?
9.3.9. Extensibility. Can you extend the basic blockchain functionality with a variety of add-ons?
9.3.10. Interoperability. Does it inter-operate well with other blockchains or related technologies?
9.3.11. Open Source. Is the code open source? What is the level of collaboration and contributions from a variety of developers?
9.3.12. Scalability.
9.4. Every organization sits at a different starting point, based on their resources and capabilities,
9.4.1. APPROACH - HOW IT’S DONE (EXAMPLES) IT Services - We will build you anything (Big IT firms) Blockchain Consulting - You work directly with the blockchain’s tools and services (Bitcoin, Ethereum, Ripple) Development Platforms - Frameworks for IT professionals (Exonum, Fabric, Eris, Truffle, Embark, Dapple, Dappsys, BlockApps, lot more...) Solutions - Industry-specific (Clearmatics, DAH, Chain) APIs & Overlays DIY assembling pieces Open Assets, Tierion
9.5. What problem is the blockchain solving?
9.5.1. Solving Problems
9.5.2. Creating Opportunities
9.5.3. Applying Capabilities
9.5.4. DECENTRALISED SERVICE CHARACTERISTICS
9.5.4.1. Speed in settlements No intermediary delays Upfront identification and reputation Flat structure with no overhead Permission-less user access Trust built inside the network Resiliency against attacks No censorship No central point of failure Governance decisions by consensus Peer-to-peer communications
9.6. Blockchain applications
9.6.1. http://techbus.safaribooksonline.com/getfile?item=c3IwczczMTFhLzlkMS9tcDlnL2llY3N0ODExMDNhc2dwZmUxamUwMGcvMXNtL2F0Y2kwLg--
9.6.2. http://techbus.safaribooksonline.com/getfile?item=c3IwczczMTFhLzlkMS9tcDlnL2llY3N0ODExMDNhc2dwZmUyamUwMGcvMXNtL2F0Y2kwLg--
9.6.3. Four types of blockchain applications (http://techbus.safaribooksonline.com/getfile?item=c3IwczczMTFhLzlkMS9tcDlnL2llY3N0ODExMDNhc2dwZmUzamUwMGcvMXNtL2F0Y2kwLg--)
9.6.4. http://techbus.safaribooksonline.com/getfile?item=c3IwczczMTFhLzlkMS9tcDlnL2llY3N0ODExMDNhc2dwZmUxamUwMGcvNnNtL2F0Y2kwLg--
9.6.5. http://techbus.safaribooksonline.com/getfile?item=c3IwczczMTFhLzlkMS9tcDlnL2llY3N0ODExMDNhc2dwZmUyamUwMGcvNnNtL2F0Y2kwLg--
10. DAPS
10.1. Advantages
10.1.1. DApps are fault-tolerant as there is no single point of failure because they are distributed by default. They prevent violation of net censorship as there is no central authority to whom the government can pressurize to remove some content. Governments cannot even block the app's domain or IP address as DApps are not accessed via a particular IP address or domain. Obviously the government can track individual nodes in the network by their IP address and shut them down, but if the network is huge, then it becomes next to impossible to shut down the app, especially if the nodes are distributed among various different countries. It is easy for users to trust the application as it's not controlled by a single authority that could possibly cheat the users for profit.
10.2. Disadvantages
10.2.1. Fixing bugs or updating DApps is difficult, as every peer in the network has to update their node software. Some applications require verification of user identity (that is, KYC), and as there is no central authority to verify the user identity, it becomes an issue while developing such applications. They are difficult to build because they use very complex protocols to achieve consensus and they have to be built to scale from the start itself. So we cannot just implement an idea and then later on add more features and scale it. Applications are usually independent of third-party APIs to get or store something. DApps shouldn't depend on centralized application APIs, but DApps can be dependent on other DApps. As there isn't a large ecosystem of DApps yet, it is difficult to build a DApp. Although DApps can be dependent on other DApps theoretically, it is very difficult to tightly couple DApps practically
10.3. DAO
10.3.1. Typically, signed papers represent organizations, and the government has influence over them. Depending on the type of organization, the organization may or may not have shareholders. Decentralized autonomous organization (DAO) is an organization that is represented by a computer program (that is, the organization runs according to the rules written in the program), is completely transparent, and has total shareholder control and no influence of the government. To achieve these goals, we need to develop a DAO as a DApp. Therefore, we can say that DAO is a subclass of DApp. Dash, and the DAC are a few example of DAOs.
10.4. Internal Currency
10.4.1. or a centralized application to sustain for a long time, the owner of the app needs to make a profit in order to keep it running. DApps don't have an owner, but still, like any other centralized app, the nodes of a DApp need hardware and network resources to keep it running. So the nodes of a DApp need something useful in return to keep the DApp running. That's where internal currency comes into play. Most DApps have a built-in internal currency, or we can say that most successful DApps have a built-in internal currency.
10.4.2. DISAADVANTAGE ABOVE
10.5. Dev platforms
10.5.1. Exonum
10.5.2. ETHEREUM
10.5.2.1. Embark
10.5.2.1.1. Automatically deploy contracts and make them available in your JS code. Embark watches for changes, and if you update a contract Embark will automatically redeploy the contracts (if needed) and the dapp. Contracts are available in JS with Promises. Do Test Driven Development with Contracts using Javascript. Keep track of deployed contracts; deploy only when truly needed. Manage different chains (e.g testnet, private net, livenet) Easily manage complex systems of interdependent contracts.
10.5.2.2. Truffel
10.5.2.2.1. AUTOMATED CONTRACT TESTING FOR RAPID DEVELOPMENT
10.5.2.2.2. BUILT-IN SMART CONTRACT COMPILATION, LINKING, DEPLOYMENT AND BINARY MANAGEMENT
10.5.2.2.3. SCRIPTABLE DEPLOYMENT & MIGRATIONS FRAMEWORK
10.5.2.2.4. NETWORK MANAGEMENT FOR DEPLOYING TO BOTH PUBLIC & PRIVATE NETWORKS
10.5.2.2.5. ACCESS TO HUNDREDS OF EXTERNAL PACKAGES
10.5.2.3. Dapple
10.5.2.4. Dappsys
10.5.3. Fabric
10.6. SPECIFIC Dapps
10.6.1. ETHEREUM
10.6.1.1. intro
10.6.1.1.1. Ethereum is a decentralized platform that allows to run DApps on top of it. These DApps are written using smart contracts (programs running on EVM). Dev creates program that runs exactly as programmed without any possibility of downtime, censorship, fraud, and third-party interference. He does not have to worry about integrating consensus protocol. Ethereum has an internal currency called ether. To deploy smart contracts or execute functions of the smart contracts, you need ether. Both user accounts and smart contracts can hold ether. A method of a smart contract can be invoked via a transaction or via another method
10.6.1.1.2. Solidity, LLL, and Serpent.
10.6.1.1.3. proof-of-work consensus protocol
10.6.1.1.4. node types (regular&mining)
10.6.1.2. accounts
10.6.1.2.1. Account represented by address derived from symmetric key pair ECC(elliptic curve cryptography). ECC has various parameters to adjust speed and security. (secp256k1)
10.6.1.2.2. Ethereum uses 256-bit encryption - private/public key is a 256-bit number. As processors cannot represent such big numbers, it's encoded as a hexadecimal string of length 64
10.6.1.2.3. How to create adress(manually): 1) Generate the keccak-256 hash of the public key -> 256-bit number. 2) Drop the first 96 bits, that is, 12 bytes. You should now have 160 bits of binary data, that is, 20 bytes. 3)Encode the address as a hexadecimal string. This bytestring of 40 characters, is account address.
10.6.1.3. transactions
10.6.1.3.1. A transaction is signed using ECDSA (Elliptic Curve Digital Signature Algorithm) data package to transfer ether from an account to another account or to a contract, invoke methods of a contract, or deploy a new contract
10.6.1.3.2. A transaction is said to be confirmed if we are sure that it will always appear in the blockchain. It is recommended to wait for 15 confirmations before assuming a transaction to be confirmed.
10.6.1.3.3. To send ether or to execute a contract method, you need to broadcast a transaction to the network and sign the transaction with sender's private key.
10.6.1.3.4. A transaction contains: 1. the recipient of the message, 2. signature identifying the sender 3. amount of ether to transfer, 4. maximum number of computational steps the transaction execution is allowed to take (gas limit) 5. cost the sender of the transaction is willing to pay for each computational step (gas price). P.S: If the transaction's intention is to invoke a method of a contract, it also contains input data, or if its intention is to deploy a contract, then it can contain the initialisation code.
10.6.1.3.5. The product of gas used and gas price is called transaction fees
10.6.1.4. consensus
10.6.1.4.1. The process of creating blocks in the proof-of-work system is called mining.
10.6.1.4.2. proof-of-stake
10.6.1.5. forking
10.6.1.5.1. A regular fork is a temporary conflict occurring due to two or more miners finding a block at nearly the same time. It's resolved when one of them has more difficulty than the other. Uncle - stale blocks.
10.6.1.5.2. A change to the source code could cause conflicts. Depending on the type of conflict, it may require miners with more than 50% of hash power to upgrade or all miners to upgrade to resolve the conflict. When it requires miners with more than 50% of hash power to upgrade to resolve the conflict, its called a soft fork, whereas when it requires all the miners to upgrade to resolve the conflict, its called a hard fork.
10.6.1.6. genesis block
10.6.1.6.1. A genesis block is the first block of the blockchain. It's assigned to block number 0. It's the only block in the blockchain that doesn't reference to a previous block because there isn't any. It doesn't hold any transactions because there isn't any ether produced yet.
10.6.1.7. denominations
10.6.1.7.1. 1 Ether = 1000000000000000000 Wei 1 Ether = 1000000000000000 Kwei 1 Ether = 1000000000000 Mwei 1 Ether = 1000000000 Gwei 1 Ether = 1000000 Szabo 1 Ether = 1000 Finney 1 Ether = 0.001 Kether 1 Ether = 0.000001 Mether 1 Ether = 0.000000001 Gether 1 Ether = 0.000000000001 Tether
10.6.1.8. peer discovery
10.6.1.8.1. For a node to be part of the network, it needs to connect to some other nodes in the network so that it can broadcast transactions/blocks and listen to new transactions/blocks.
10.6.1.8.2. Ethereum has its own node discovery protocol (Kadelima based) to solve this problem. In the node discovery protocol, we have special kind of nodes called Bootstrap nodes. Bootstrap nodes maintain a list of all nodes that are connected to them over a period of time. They don't hold the blockchain itself. When peers connect to the Ethereum network, they first connect to the Bootstrap nodes ,which share the lists of peers that have connected to them in the last predefined time period.
10.6.1.8.3. mainnet and testnet
10.6.1.9. Geth
10.6.1.9.1. command line interface for running a full ethereum node implemented in Go.
10.6.1.9.2. Geth provides JSON-RPC APIs for other applications to communicate with it. Geth serves JSON-RPC APIs using HTTP, WebSocket, etc...
10.6.1.9.3. To use fast sync while downloading the blockchain, you need to use the --fast flag while running geth.
10.6.1.10. Ethereum wallet
10.6.1.10.1. Ethereum UI client that lets create account, send ether, deploy contracts, invoke methods of contracts. Comes with Geth bundled
10.6.1.10.2. ethereum/mist
10.6.1.11. Mist
10.6.1.11.1. The most popular feature of Mist is that it comes with a browser. Currently, the frontend JavaScript running in the browser can access the web3 APIs of the geth node using the web3.js library (a library that provides Ethereum console's JavaScript APIs for other applications to communicate with geth).
10.6.1.12. Weaknesses
10.6.1.12.1. Bugs, DoS attack
10.6.1.12.2. Sybil attack
10.6.1.12.3. 51% attack
10.6.1.13. Whisper/Orbit to send/receive messages through channels in P2P
10.6.1.14. IPFS & SWARM
10.6.1.15. Metamask
10.6.1.16. ethereumjs-testrpc
10.6.1.16.1. A simple Ethereum testnet node for development. Works as a substitute for the real Ethereum network
10.6.2. TON
10.6.2.1. Infinite sharding paradigm
10.6.2.1.1. Blockchain of blockchains
10.6.2.1.2. 2^32 workchains which consist of 2^60 shardchains
10.6.2.1.3. Workchain 0 - Gramm currency
10.6.2.2. Human readable names to accounts
10.6.2.2.1. right sidebar
10.6.2.2.2. next to menu
10.6.2.2.3. top right corner
10.6.2.3. BFT + POS
10.6.2.4. Q1 2018 build in KYC in telegram
10.6.3. Bitcon
10.6.3.1. Nakamoto key ideas: 1) Peer-to-peer electronic transactions and interactions 2) Without financial institutions 3) Cryptographic proof instead of central trust 4) Put trust in the network instead of in a central institution
10.6.4. Ripple
10.6.4.1. Usecase
10.6.4.1.1. Let's look at an example of how user X living in India can send 500 USD to user Y living in the USA. Assuming that there is a gateway XX in India, which takes cash (physical cash or card payments on their website) and gives you only the INR balance on ripple, X will visit the XX office or website and deposit 30,000 INR and then XX will broadcast a transaction saying I owe X 30,000 INR. Now assume that there is a gateway YY in the USA, which allows only USD transactions and Y trusts YY gateway. Now, say, gateways XX and YY don't trust each other. As X and Y don't trust a common gateway, XX and YY don't trust each other, and finally, XX and YY don't support the same currency. Therefore, for X to send money to Y, he needs to find intermediary gateways to form a trust chain. Assume there is another gateway, ZZ, that is trusted by both XX and YY and it supports USD and INR. So now X can send a transaction by transferring 50,000 INR from XX to ZZ and it gets converted to USD by ZZ and then ZZ sends the money to YY, asking YY to give the money to Y. Now instead of X owing Y $500, YY owes $500 to Y, ZZ owes $500 to YY, and XX owes 30,000 INR to ZZ. But it's all fine because they trust each other, whereas earlier, X and Y didn't trust each other. But XX, YY, and ZZ can transfer the money outside of ripple whenever they want to, or else a reverse transaction will deduct this value.
10.6.4.2. How it works
10.6.4.2.1. Ripple Ripple is decentralized remittance platform. It lets us transfer fiat currencies, digital currencies, and commodities. It uses the blockchain data structure and has its own consensus protocol. In ripple docs, you will not find the term blocks and blockchain; they use the term ledger instead. In ripple, money and commodity transfer happens via a trust chain in a manner similar to how it happens in a hawala network. In ripple, there are two kinds of nodes, that is, gateways and regular nodes. Gateways support deposit and withdrawal of one or more currencies and/or commodities. To become a gateway in a ripple network, you need permission as gateways to form a trust chain. Gateways are usually registered financial institutions, exchanges, merchants, and so on. Every user and gateway has an account address. Every user needs to add a list of gateways they trust by adding the gateway addresses to the trust list. There is no consensus to find whom to trust; it all depends on the user, and the user takes the risk of trusting a gateway. Even gateways can add the list of gateways they trust. Ripple also has an internal currency called XRP (or ripples). Every transaction sent to the network costs some ripples. As XRP is the ripple's native currency, it can be sent to anyone in the network without trust. XRP can also be used while forming a trust chain. Remember that every gateway has its own currency exchange rate. XRP isn't generated by a mining process; instead, there are total of 100 billion XRPs generated in the beginning and owned by the ripple company itself. XRP is supplied manually depending on various factors. All the transactions are recorded in the decentralized ledger, which forms an immutable history. Consensus is required to make sure that all nodes have the same ledger at a given point of time. In ripple, there is a third kind of node called validators, which are part of the consensus protocol. Validators are responsible for validating transactions. Anyone can become a validator. But other nodes keep a list of validators that can be actually trusted. This list is known as UNL (unique node list). A validator also has a UNL; that is, the validators it trusts as validators also want to reach a consensus. Currently, ripple decides the list of validators that can be trusted, but if the network thinks that validators selected by ripple are not trustworthy, then they can modify the list in their node software. You can form a ledger by taking the previous ledger and applying all the transactions that have happened since then. So to agree on the current ledger, nodes must agree on the previous ledger and the set of transactions that have happened since then. After a new ledger is created, a node (both regular nodes and validators) starts a timer (of a few seconds, approximately 5 seconds) and collects the new transactions that arrived during the creation of the previous ledger. When the timer expires, it takes those transactions that are valid according to at least 80% of the UNLs and forms the next ledger. Validators broadcast a proposal (a set of transactions they think are valid to form the next ledger) to the network. Validators can broadcast proposals for the same ledger multiple times with a different set of transactions if they decide to change the list of valid transactions depending on proposals from their UNLs and other factors. So you only need to wait 5-10 seconds for your transaction to be confirmed by the network. Some people wonder whether this can lead to many different versions of the ledger since each node may have a different UNL. As long as there is a minimal degree of inter-connectivity between UNLs, a consensus will rapidly be reached. This is primarily because every honest node's primary goal is to achieve a consensus.
10.6.5. DASH
10.6.5.1. Dash is a decentralized currency similar to Bitcoin. Dash uses the blockchain data structure and the proof-of-work consensus protocol. Dash solves some of the major issues that are caused by Bitcoin. Here are some issues related to Bitcoin: Transactions take a few minutes to complete, and in today's world, we need transactions to complete instantly. This is because the mining difficulty in the Bitcoin network is adjusted in such a way that a block gets created once in an average of every 10 minutes. We will learn more about mining later on in this book. Although accounts don't have an identity associated with them, trading Bitcoins for real currency on an exchange or buying stuff with Bitcoins is traceable; therefore, these exchanges or merchants can reveal your identity to governments or other authorities. If you are running your own node to send/receive transactions, then your ISP can see the Bitcoin address and trace the owner using the IP address because broadcasted messages in the Bitcoin network are not encrypted.
10.6.5.2. To host a masternode, you need to have 1,000 Dashes and a static IP address. In the Dash network, both masternodes and miners earn Dashes. When a block is mined, 45% reward goes to the miner, 45% goes to the masternodes, and 10% is reserved for the budget system. Masternodes enable decentralized governance and budgeting. Due to the decentralized governance and budgeting system, Dash is called a DAO because that's exactly what it is. Masternodes in the network act like shareholders; that is, they have rights to take decisions regarding where the 10% Dash goes. This 10% Dash is usually used to funds other projects. Each masternode is given the ability to use one vote to approve a project. Discussions on project proposals happen out of the network. But the voting happens in the network. Masternodes can provide a possible solution to verify user identity in DApps; that is, masternodes can democratically select a node to verify user identity. The person or business behind this node can manually verify user documents. A part of this reward can also go to this node. If the node doesn't provide good service, then the masternodes can vote for a different node. This can be a fine solution to the decentralized identity issue.
10.7. Consensus algorithms
10.7.1. when discussing consensus algorithm, you need to consider the “permissioning” method, which determines who gets to control and participate in the consensus process. The three popular choices for the type of permissioning are: Public (e.g., POW, POS, Delegated POS) Private (uses secret keys to establish authority within a confined blockchain) Semi-private (e.g., consortium-based, uses traditional Byzantine Fault Tolerance in a federated manner)
10.7.2. POW, POS(relies on the concept of virtual mining and token-based voting, a process that does not require the intensity of computer processing as the POW, and one that promises to reach security in a more cost-effective manner), RAFT, DPOS, and Paxos