Ethereum is a well-established blockchain that enables developers to create smart contracts — programs that execute on blockchain that can be triggered by transactions. People often refer to blockchain as a database but using blockchains as a data store is prohibitively expensive.
IPFS (InterPlanetary File System) is protocol establishing the peer-to-peer network with resources addressed based on their content instead of the physical location like in HTTP. IPFS gives us some guarantees of blockchains like decentralization and unalterable storage at a fraction of the price you would have to give in transaction fees. Participation in the IPFS network is free.
Nebulas is yet another platform on which you can develop smart contracts. It offers a means of using JavaScript to develop Smart Contracts — an intriguing alternative to more established solutions, such as Ethereum.
Decentralized applications present a new set of challenges. One of them is testing. Transaction lifecycle is more complex than the old-school POST request/response flow and errors are often less than helpful. Although developer experience is getting better, this puts into perspective how testing is essential.
Cee, five, ef, dee, ef, four, ow, six, seven, oh wait, it’s ow, seven, six, bee… That’s of course not the way you would like to share your Ethereum address or Swarm and IPFS content hash. You copy and send it or scan QR codes but this experience is still inferior to using easy to remember, readable names. In the same way, as DNS solved this problem for IP addresses, ENS has a goal of mitigating this issue in Ethereum ecosystem.
Why would you like to verify your smart contract? It depends. It mostly depends on your use case. It always comes down to being transparent. If I were into ICOs, I would want to make sure that the token and the crowdsale contract code enforces cryptoeconomics described in the whitepaper (or, ugh…, in the video). Open sourcing the code on GitHub is a great idea but gives no guarantees that the code in the repository is even remotely similar to the one running on-chain. It is a contract after all so it would be good to give other parties a chance to familiarize with the conditions they are going to “sign”. Verify the source code even if not everyone has programming skills to read it.
Docker is the response to an ongoing problem of differences between environments in which application runs. Whether those differences are across machines of the development team, continuous integration server, or production environment. Since you are reading this, I assume you are already more or less familiar with benefits of containerizing applications. Let’s go straight to Node.js specific bits.
Truffle provides a system for managing the compilation and deployment artifacts for each network. To make an actual transaction and put a smart contract on-chain we have to provide Truffle with an appropriate configuration. We configure each network separately. From this post, you will learn how to prepare a setup and deploy to a few widely used test networks.
This is the second part of the test-driven introduction to Solidity. In this part, we use JavaScript to test time-related features of our smart contract. Apart from that, you will see how to check for errors. We will also complete the rest of the smart contract by adding withdrawal and refund features.
Depends on how you count, second and third generation blockchain applications are not bound by restrictions of underlying protocols. Programmers can create smart contracts — distributed applications with access to code-controlled accounts. Use cases go far beyond exchanging value and applies where users benefit from replacing trust between parties with code.