Blockchains

An overview of Blockchain-related work performed at the CSG since 2014, including the full set of CSG team members, students, their papers and theses, and respective talks, is available in the IfI Technical Report IFI-2019-01 (PDF, 1 MB) .

In recent years, electronic contracts have gained attention, especially in the context of the blockchain technology. While public blockchains - sometimes called distributed ledgers as well - are considered secure, legally binding under certain circumstances, and without any centralized control, they apply to a wide range of application domains, such as public registries, registry of deeds, or virtual organizations. As one of the most prominent blockchain examples, the Bitcoin system has reached a broad public, financial industry-related, and research interest. Another notable blockchain example, Ethereum, which is considered a general approach for smart contracts, has taken off too. Nevertheless, various set of functions, applications, and stakeholders are involved in this smart contract arena. These need to be put into interrelated technical, economic, and legal perspectives.

In general, smart contracts need to run on a blockchain to ensure (a) its permanent storage and (b) extremely high obstacles to manipulate the contract’s content. A node participating in the blockchain runs a smart contract by executing its script, validating the result of the script, and storing the contract and its result in a block. A block stores multiple smart contracts and is typically created at a constant time interval. For instance, Bitcoin had chosen to create a block every 10 minutes, while Ethereum blocks are created every 14 seconds. A block always has a reference to the previous block, forming a chain of blocks, hence the term blockchain (cf. Figure 1). In general, a block contains an increasing block number, a hash, a reference to the previous block, a crypto puzzle’s solution in case of Proof-of-Work (PoW), and one or several transaction-related content information with encoded smart contracts.

Figure 1: Blockchain Example

Figure 2 shows the big picture, how the blockchain is used by users, miners, and exchanges – the three key stakeholders in such an approach. When a user sends coins to other users, it creates a smart contract, encodes the contract in a transaction, and broadcasts the transaction. The recipient user may see the transaction broadcasted within seconds, but as this transaction is not yet in the block-chain, double spending is still possible. The miner also will receive the transaction broadcasted and will start to solve the crypto puzzle. Once a puzzle is solved by a miner, the block will be broadcasted to all peers and other miners will know that they have to restart their process and start solving another crypto puzzle. 

Figure 2: The Big Picture of Blockchain Stakeholders with Miners, Users, Blockchain, and Exchanges 

Every block that contains a solved crypto puzzle will be added to the blockchain by each node in the system by applying the consensus mechanism in case of needs. The miner that solved the crypto puzzle gets rewarded and can use these coins or exchange them to a government-issued currency at an exchange site. This is often required as electricity bills are typically paid with “fiat” currency. Any user receiving bitcoins can also exchange these to fiat currency. Exchange sites, such as Bitstamp, the first EU-licensed Bitcoin trading site, require the user to register and conform to regulations such as Know Your Customer (KYC). Such regulations are not required when transferring bitcoins, however, as soon as bitcoins are exchanged to a government-issued currency (e.g., US$ or €), a user can be identified. 

The Coinblesk project implemented, tested, and operationally deployed an open source solution, where Bitcoin payments are possible through a mobile device in real-time (below 1 s). The Android app called Coinblesk includes a Bitcoin payment server, where the seller and the buyer will be able to handle Bitcoin payments. For the communication between the buyer and the seller NFC equipped devices will be used. 

The combination of IoT temperature sensors and their data generated with the blockchain technology revealed a highly efficient, secure, and demand-driven approach in support of the pharmaceutical industry. This is because such an approach provides data integrity for transaction data of physical products. Thus, the supply chain processes in many sectors can be streamlined. 

The approach developed from the CSG for the core of the start-up modum.io solution records environmental conditions (here temperature) during the shipment of the product and stores them in the Ethereum blockchain. Thus, at the handover of boxes (e.g., from the manufacturer to the logistics company) the data collected is checked against the product's corresponding smart contract (here being part of the Ethereum blockchain). This contract triggers the final operations to guarantee that the transport had met all of the conditions put forth by formal regulations or customer demands. 

This work won the Zürich Kickstart Accelerator's 1st Place​ in November 2016 and received some small funding from the Venture Kick in Lausanne in August 2016. 

The rapid growth in the number of portable and stationary devices makes Distributed Denial-of-Service (DDoS) attacks a top security threat to securely provision services and scale through automation. Existing defense mechanisms lack resources and flexibility to cope with attacks by themselves, and by utilizing other's companies resources, the burden of the mitigation can be shared. Emerging technologies such as blockchain, smart contracts, and SDN (Software-defined Networking) introduce new opportunities for flexible and efficient DDoS defense solutions across multiple domains. 

This work proposes the design of an architecture and smart contract deployed in a public blockchain, which facilitates a collaborative DDoS mitigation architecture across multiple network domains. The advantages of this design are the use of an already existing public infrastructure to distribute DDoS defense rules without the need to build specialized registries or other (complicated, non-trusted) distribution mechanisms. At the same time, such an approach enables the enforcement of such rules across multiple domains in a trusted manner.