Introduction In episode 1, Miki had two functions that performed the similar operation, but returned different types. To refactor this, Miki rewrote both functions as a generic function that allowed him to specify the type to be returned during invocation. In some cases, the compiler may not recognise a type, thus, Miki gives a few pointers on manually telling a generic function which type to use. After demonstrating how to return different types with a generic function, Miki limited the types his generic function would accept with an interface.
Continue reading

Introduction Go interfaces are beneficial to Go developers because they: Allow interfaces to separate mechanism from behavior. Increase flexibility of function parameters. Enable mocking of function parameters. With the addition of generics in Go 1.18, interfaces can be used to constrain the types of values a generic function will accept. To dive deeper into Go interfaces, we invite you to join Miki in his latest series dedicated to Go interfaces.
Continue reading

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