Introduction In episode 19, Bill designed and implemented the data structure for an account on his blockchain. This type will have a nonce field to ensure incoming transactions are valid and performed in order. Since the database will be stored in memory and not on disk, the balances in these accounts are reconstructed with information from previous transactions and the genesis block. In this video, Bill takes all the theories discussed in this series and applies them by launching his first blockchain node.
Continue reading

Introduction In episode 18, Bill defined the Go type that will represent a transaction and implemented the methods to validate one. While developing the transaction type, Bill states that he’ll be borrowing concepts from Ethereum to ensure that he’s building a reference implementation. Bill’s transaction type has a field named nonce, similar to Ethereum, that ensures transactions are executed in order. The nonce value of the last transaction is stored in his accounting database and later compared for additional verification.
Continue reading

Introduction In episode 17, Bill began to design an in-memory accounting database that will store the account balances on his blockchain. To build this database, Bill will add a memory pool on each node that stores a list of public addresses with their respective balances. The balances on these addresses are reconstructed by reading the previous transaction records found on his blockchain. In this video, Bill will define the types of transactions his blockchain will support.
Continue reading

Introduction In episode 16, Bill implemented additional means of verification for his blockchain’s transactions. The first update he made was to verify if a transaction is destined for his blockchain by reading the first byte of the signature. The next one Bill made was to recalculate the public address from a signature and compare it with the from field of the transaction to verify if the request is valid. While building this, Bill demonstrates how a user’s private key transforms into their public address.
Continue reading

Introduction Table tests are a great way to test different inputs and associated outputs for a function in Go. To write a table test, you define a slice of some data struct with fields of the input data you’ll need and the expected outcome. Then you can loop through this slice and pass the data stored for each element to your function. One disadvantage of table tests is as the data set in your slice grows, the harder it is to find the failing case.
Continue reading

Introduction When an API requires implementation details from the user, many developers use an interface for help. However, another way to allow developers to provide implementation details for an API is to accept a function instead. Go supports declaring function types which can be used to define a contract similar to how interfaces define a contract. A good example of an API that uses functions over an interface is the HTTP package.
Continue reading

Introduction In episode 15, Bill architected a solution to ensure all the users on his blockchain were given a unique identifier. His approach consisted of essentially leveraging the randomness of a user’s private key to ensure each identifier is unique. A disadvantage Bill pointed out with this is that a user may forget their private key and ultimately lose access to their account. To circumvent this issue, Bill proposed the usage of a mnemonic, that is composed of 12 to 24 words, to act as the private key since it’s simpler to keep track of and hard to guess.
Continue reading

Introduction Google developed Go to be an alternative to C++ with the internet and scale in mind. Go’s toolchain automates tasks that are easily overlooked, and amongst those tasks is generating documentation. Go has the ability to generate documentation based on comments written in your source code. As the end user, you have the choice to view this documentation in your terminal or, if your code is publicly accessible, on pkg.
Continue reading

Introduction In episode 14, Bill architected a solution to digitally sign the transactions on his blockchain. His solution retrieved the private key by : loading private key data from disk, parsing the key data and returning the ECDSA private key. The private key is then used to generate the signature of a transaction. While writing the code to perform this functionality, Bill highlighted how a blockchain node can use a transaction’s signature to extrapolate the public key.
Continue reading

Introduction In episode 13, Bill discussed the idea of adding salt to a hash and how modern crypto-currency blockchains use it to better interpret requests sent to nodes. He continued by defining a function called stamp that embeds a salt within a hash. While writing the function, Bill stated that he would use keccak256 as it’s the same algorithm used by Ethereum to generate hash values. Bill will use the APIs provided with Go Ethereum to generate a keccak256 hash.
Continue reading