By Florian Wessling
Blockchain is a big hype. Basically, it is “a database that can be shared between a group of non-trusting individuals, without needing a central party to maintain the state of the database”. In other words, it avoids a trusted third party. In Ethereum, they store “consensus about world state”, being the value of objects. These objects can be changed using transactions. Each node stores the latest world state. The transaction is sent to each peer (over a peer-to-peer network), after which the peers need to get consensus of the state. Once this consensus is reached, a new transaction can start.
As everybody wants a blockchain-based applications nowadays, how do you design one? How do you handle the different properties, like decentrality, trustless environments. consensus mechanisms, etc. What are best practices? Or architectural patterns? Are there design patterns for smart contracts? This leads to his initial research question “How to determine the architecture of a blockchain-based application?”.
As a first step, he looked into architectural patterns currently exist. Up to now, he found 1) self-generated transactions (directly generated by the user), 2) Self-confirmed transaction (transaction is created via some website, and then confirmed by the user), and 3) delegated transactions (via some intermediate service the transaction is generated).
General outlook of his PhD research is to find architectural patterns and best practices of when and how blockchain can help you. Fun research, maybe he can use our paper as a case study đŸ™‚