Blockchain Engineering projects - class of 2021

[synctext]

Online Lecture URL

The URL for the lectures is this WebEx link (for each of the 8 lectures). The password for this meeting can be found in the Brightspace announcements.

Project descriptions for CS4160 master course

Official place for "class projects" of the Feb 2021 edition of CS4160 by Delft University of Technology. Prior year examples: 2020 edition projects, 2018 projects.

class schedule:

Week	Description
3.1	Presentation of available projects and formation of teams (each 4-5 students)
	8:45 - 9:45 : present all available projects
	9:45 - 10:30 : self-organise and form teams of 4-5 students. Professors available for questions
3.2	Introduction to blockchains, Bitcoin, ledger technology, and DAO (slides)
	short 10 minute introduction to Superapp
3.3	Detailed blockchain engineering using: https://github.com/grimadas/BlockchainEngineering (no slides, .ipynb only)
	Distributed systems. Overlays and communication network. Introduction to simulation framework
	Gossip. Convergence of the transactions, information
	Faults in distributed systems: crashes and disruptions
	Malicious nodes, adversary model
	Consensus and agreement despite malicious nodes
3.4	IPv8 documentation, the tutorial and Trustchain
3.5	European token regulations - Authority Financial Markets (final class lecture)

Project: self-evolving AI-DAO (4 teams, maximum 20 students)

Advisor: J.A. Pouwelse, TUDelft blockchain lab founder (weekly meetings on Wednesdays)

Student from Delft have created a blockchain-based alternative to Spotify. Completely decentralised. Uses Bittorrent for streaming, Bitcoin for payments to artists, Trustchain with IPv8 for music discovery and IPv8 for app-to-app connectivity. With multiple teams the aim is to take this code to the next level: self-evolution.

A total of 4 students teams (4-5 students in each team) will work together on a cutting-edge scientific problem: how to create a software system which can be expanded in real-time and increasingly become more 'intelligent'. Build upon the existing open source app by TUDelft on the Android Play store using blockchain technology: the Superapp. You will help transform essential parts of the music industry and replace them with open source software. Current code:

GIF: Browsing and streaming music with Bittorrent

GIF: Sending money to artists using Bitcoin

DAO - organisations in software

To make a "self-evolving" app we use the DAO concept. What is a DAO? Within the coming decades the future of jobs, employment and the nature of the firm will change profoundly. Automation, AI, and robots will replace many of today's jobs. A new type of company is a company without any employees, without any machines or physical infrastructure. A Decentralized Autonomous Organizations, DAO, only exists in software. It goes beyond smart contracts, it is a complete company inside software. DAO development is still in the experimental stage. Background reading. Very optimistic view on DAO, official US review of DAO by Securities and Exchange Commission.

Within this master course you can create your very own autonomous organisation, the AI-DAO. Learn to engineer a decentralised autonomous organisation, use the existing tools, and understand the security risks. The aim is to alter the nature of the firm in the Internet age, see the Nobel prize winning theory. Production cost become essentially cost-free. An organisation which exists purely in cyberspace. The AI-DAO is designed to be the first sustainable DAO. How can we empower leaderless organizations? How can it earn money from manipulating bits?

Scientific challenge: Self-evolving

A key step in an autonomous system is that it can evolve independently. This enables growth and evolution independently of any central organisation, sponsoring government, or tribe of volunteers.

You will collectively solve the problem of paying somebody to make new features in open systems which are fully decentralised. This goes further then paying somebody Bitcoins to create a new version. Decentralised technology is very robust to failures, manipulation, faults, and courtcases. For instance, The Internet itself is almost impossible to shutdown so is the "Tor darknet". With other teams you will address a key drawback of decentralised technology: difficult to update, nearly impossible to evolve, and lacks incentives to develop new features.

dApp ecosystem

"Distributed Applications" are a distributed way of running code. You will help develop an ecosystem of "global code". Code is running atop a blockchain and peer-to-peer (P2P) network that acts as a kind of operating system. This provides security, resilience, privacy, and novel features. This is related to smart contracts, but has no slow single virtual machine (all discussed in the online classes material). Background material, read FBASE trustworthy code execution

PNG: difference between cloud and decentralised Apps

4 teams of 4-5 students per team.

The task of building the "self-evolving AI-DAO" has been broken into 4 parts. The course finishes when your all your pull requests are accepted upstream and your part works.

• TEAM P1: the first AI-dApp (4-5 students)
  Create a dApp with federated machine learning to understand music taste of user and recommend more. Exchange training vectors on the blockchain overlay. Never share with others what Bittorrent music swarms you like. By only sharing training data you can discover new music and still preserve privacy. Prior work and this.
• TEAM P2: dApp execution environment (4-5 students)
  Closely working with the Android OS. Download code in .jar format using Bittorrent. Live code injection to update Android code. Bypass the Android security model. Solve the state preservation problem. Facilitate the discovery of new code. Spread magnet links to dApps and their attached Bitcoin bounty wallet address. Prior work
• TEAM P3: Bounty payout voting and payment execution (4-5 students)
  Your team ensures people get paid for evolution of features. Use muti-sig wallet and quorum-based voting to create real-world Bitcoin payouts. Sync the vote progress with others, visualise as votes come in (approve or reject) and display the undecided votes. Any developer can contribute code to the DAO and get paid. It disconnects the DAO from any bank, government, and legal system. Help create a global economy that is hyper-efficient, fair, honest, and digital. prior work
• TEAM P4: DAO runtime system (4-5 students)
  Your responsibility is to create an operational DAO. Your work ensures any group of people of unlimited size can control an unbounded amount of Bitcoin. Any user can create a DAO, get discovered, and grow. Join any DAO and manage the multi-signature wallet. Create a background task which verifies new members, checks their entry fees, automatically approves them, and shows the vote approval status of any pending new member. Build up a deep understanding of P2SH transactions which utilise threshold encryption.
  prior work

Running code

We have running code! Class of 2021 is adding the following to the Superapp:

• OPERATIONAL Machine learning the first AI dAPP - self-evolving AI-DAO #5987
• OPERATIONAL Multi-Signature Bitcoin wallet Bounty payout voting and payment execution - self-evolving AI-DAO #5986
• OPERATIONAL liquidity pool Euro-Bitcoin A Mobile and Generic Asset Exchange using Liquidity Pooling [group 2] #5996
• OPERATIONAL liquidity pool Bitcoin-Ethereum A Mobile and Generic Asset Exchange using Liquidity Pooling [group 1] #5988

[devos50]

A Mobile and Generic Asset Exchange using Liquidity Pooling

Ever since the introduction of Bitcoin, there has been a proliferation of blockchain-based currencies and applications. Nowadays, the majority of blockchain-based applications orient around decentralized finance (DeFi), an experimental form of finance that enables value transfer and exchange directly between participants, without intermediaries. The number of different DeFi application is quickly growing. Many of these DeFi applications are deployed using smart contract logic, e.g., on Ethereum.

Currently, decentralized exchanges (DEXes) make up a significant part of the DeFi landscape. DEXes enable the trade between different pairs of digital assets, without risks. Some DEXes facilitate trade by having traders create buy and sell orders and automatically execute orders when a trading opportunity arises. Newer DEXes like Uniswap use a different approach to trade assets. In this approach, there is a pool for every pair of assets, and users can deposit assets in these pools. Such users are called Liquidity Providers and are rewarded with special 'share' tokens. Traders can then exchange asset A for B by depositing asset A in the pool, in exchange for asset B.

Existing DEXes using liquidity pooling only allow the trade of assets that are locked to the ecosystem in which the DEX operates. For example, Uniswap can only exchange Ethereum-based assets, significantly limiting the applicability of this approach. Recently, we have introduced an approach to enable generic asset trading using traditional order books (we will share the paper with you at the start of the project). This approach enables the trade of any asset, managed by any ecosystem. Risks are manageable by splitting up a trade into a series of smaller, intermediate payments.

The goal of this project is to engineer a basic and generic DEX, based on Liquidity Pooling. All operations and asset transfers will be recorded on TrustChain, our lightweight distributed ledger. This approach makes it possible to detect fraudulent behavior, specifically stealing assets. You will integrate this application in our Superapp, which already has several decentralized applications integrated and deployed (e.g., for social networking, music streaming, and federated machine learning). Your final demo will show a simple asset exchange between two real cryptocurrencies, e.g., Bitcoin and Ethereum tokens. For simplicity, you may assume that the liquidity pool will be managed by a trusted identity in the network.

(image source: https://uniswap.org/docs/v2/protocol-overview/how-uniswap-works/)

[zekierkin]

Z1: Efficient Transaction Advertisement Protocol

Existing blockchain solutions suffer from multiple broadcasting of the same transaction over the network. Each transaction is received by the nodes (miners) in the network twice: once during the advertisement, i.e. broadcasting of the transaction at the beginning, and once after the validation, i.e. broadcasting of the block including the transaction. While validation is essential since each node in the network stores every validated transaction, the advertisement does not need to be received by all nodes.

In [1], the authors propose a smart routing protocol that reduces the redundant transaction advertisement from the size of the network to a factor of the average shortest path length. The routing mechanism is built upon a specific type of consensus protocol where the round leader who creates the transaction block is known in advance.
An example of the consensus protocols is the Bitcoin-NG protocol [2].

In this project, you will review the existing (draft) implementations of Bitcoin-NG provide a complete implementation of Bitcoin-NG implement the routing protocol given in [1], test and compare the existing routing protocol with the one in [1]

Deliverables: Code, setup for test and comparison, report

References:
[1] Ersoy, O., Ren, Z., Erkin, Z. and Lagendijk, R.L., 2018, June. Transaction propagation on permissionless blockchains: incentive and routing mechanisms. In 2018 Crypto Valley Conference on Blockchain Technology (CVCBT) (pp. 20-30). IEEE.
[2] Eyal, I., Gencer, A.E., Sirer, E.G. and Van Renesse, R., 2016. Bitcoin-ng: A scalable blockchain protocol. In 13th USENIX symposium on networked systems design and implementation (NSDI 16) (pp. 45-59).

[zekierkin]

Z2: Supply Chain Visibility (SCV) assignment
Customer: Wout Hofman (TNO)

Assignment

To create a supply chain visibility blockchain network with a visualization dashboard to support any actor. Whenever possible, events providing visibility generated by physical activities (load, discharge, arrive, depart, etc.) should be automatically distributed (i.e. with minimal user intervention) to customers and next legs in a chain.
A blockchain infrastructure should be created in such a way that actors cannot derive which other actors share data with each other (commercial sensitivity exposed by data). Preferably, a demonstrator should be developed of a network in which a large number of enterprises collaborate. The demonstrator should have a dashboard monitoring all chains in the network (a network manager) and one for each individual enterprise in the network.

Systems environment
The focus is on any actor participating in a supply and logistics network. Each actor may have customers and services providers with a contractual relation depicted by business transactions:

An actor may bundle business transactions of customers into one business transaction to a service provider or split one customer business transaction over several service providers. Each service provider may perform a leg in a chain or several services providers may compete for the same leg. An example is that there are many carriers able to transport containers from and to the Rotterdam Port.
A customer in this example, also an actor, will have no orders (in terms of logistics operations). In the previous figure, a service provider is also an actor, however without any outsourcing to another actor.
A ‘chain’ is a timed sequence of physical activities for a (group of) object(s), where each activity is performed by a different actor. The chain is controlled by another actor, similar to what is shown in the figure. A dashboard should support an actor in configuring supply chain visibility (see further) and assess progress or exceptions (e.g. too late, too early, objects missing, etc.) in its chains.

Interfaces

A service provider will have a transport means like a truck or vessel calling upon various locations to load and discharge objects (e.g. packages, pallets, containers). This is called an itinerary: a timed sequence of events with the following properties and values of ‘event’:
• Milestone – values: load, discharge, arrive, depart,... (each value of a milestone gives another event)
• Phase – values for the properties planned and estimated date/time of the milestone
• Associations – the objects, a location, and a transport means.
A business transaction consists of two events in which two actors are involved:
• Milestone – values: ‘accept’ and ‘deliver’. When a carrier loads objects, it is ‘accepted’; discharge means ‘deliver’. So ‘accept’ and ‘deliver’ are related to the milestone values ‘load’ and ‘discharge respectively.
• Phase – values for the properties expected date/time of a milestone
• Associations – the objects, two locations (one for accept and another for deliver),
and two actors (customer and service provider roles).
Whenever progress takes place, this is signalled by an event to a customer with the following properties:
• Milestone – values: depending on the customer business transaction and the position in the chain. For a transport means: values ‘load’, ‘discharge’, ‘arrive’ and ‘depart’. For a customer business transaction: ‘accept’ or ‘deliver’.
• Phase – values of the property actual date/time of a milestone
• Associations – these should be the association in (1) a business transaction or (2)
itinerary events (see before).

Processing (‘smart contracts’, ‘chain code’, etc.)

First of all, the system needs to be configured. This by sharing itinerary – and business transaction events. These set the basic conditions.
Secondly, a transport means will start the process by generating an event with a milestone. This can be an estimate (e.g. estimated arrival at a location) or actual (e.g. objects are loaded on a truck).
The following actions take place:
• Customer events: the event is distributed to all actors that have a business transaction with the relevant object(s). Whenever a ‘customer’ receives this event, it can trigger a new event (recursivity).
• Leg synchronization event: there is a next leg in a chain that requires an update event based on changes in planning (e.g. estimated and actual indicate a delay or early performance of a milestone).
This ‘simple’ explanation needs further elaboration. See also background documentation.

Background documentation

Background document is the document of FEDeRATED on Supply Chain Visibility (http://www.federatedplatforms.eu/index.php/library/category/2-masterplan - the Semantics - Supply Chain Visibility Ledger document).

[zekierkin]

Z3 Token based Supply Chain Finance
Customer: BlockLab
Introduction
The use of physical inventory as collateral to obtain financing has been around for hundreds of years. Even in 2021 this is still very much a paper process relying on custom documents such as the bill-of-lading and the letter-of-credit. While blockchain platforms such as Komgo and Marco Polo focus on the digitization of these documents to make the process more efficient, the real disruption would be to finance against the “digital twin” of the inventory.

Inventory Finance by Logistics Service Providers (LSPs)
LSPs store inventory on behalf of their clients. While they do not become owner of the goods themselves, they do have the right of “retention”. This means that they can keep control over the inventory until their client has paid all the charges associated with that inventory. Furthermore, they possess important data about the client itself and the value of the goods and its condition. A high-level description of that data is already available within Blocklab.

Solution
Combining so-called “proof-of-existence” and “proof-of-ownership” of the inventory with the other available data would allow tokenization of the inventory. These tokens could then be used as collateral to obtain financing.
In order to be able to provide “proof-of-existence” the solution needs to be able to obtain untampered and reliable inventory records from a Warehouse Management System (WMS) Oracle. Based on the “proof-of-existence” and other relevant data, a non-fungible token should be created that adheres to the Ethereum standard to provide “proof-of-ownership”.

Platform
For the integration with the WMS and the development of the Oracle students will use the Baseline protocol. This platform furthermore provides the possibility to model and deploy Zero Knowledge proofs. For “proof-of-ownership”, Blocklab uses the TradeTrust framework. Both Baseline and TradeTrust are available as open-source software.

Baseline : https://github.com/ethereum-oasis/baseline/tree/bri-1-privacy/examples/bri-1/base-example

TradeTrust : https://github.com/TradeTrust

[zekierkin]

Z4: BlockCert: Supply Chain Logistics

Customer: TNO, TU Delft, Windesheim

Spark! Living Lab (https://sparklivinglab.nl/) explores the application of blockchain technology within supply chain and logistics. One of the use cases currently explored together with companies is BlockCert. BlockCert aims to digitize certifications in agri-food, in order to create a more transparent and efficient data transfer in supply chain.

At least 3 parties are involved in the current process: a producer (of French fries), a grower (of potatoes) and an independent certification body. A grower needs to be certified to be allowed to supply potatoes to the producer. Currently, the producer doesn’t have real-time insights in the certification status of the growers. When the grower isn't in time with submitting a yearly updated certificate, they are not allowed to deliver their potatoes. Nowadays the issuer shares an Excel file with this information with the producer, but there are other certification bodies as well, making the process slow and difficult.

Within this assignment, you create a blockchain-based solution to issue, validate and revoke certifications. The teams will create running code that supports these requirements:

• Create tokenized certification
  • Define overall architecture
  • Use the Token Taxonomy Framework to define the most suitable token definition
  • Select the most suitable blockchain platform and frameworks to support the needs of the customer(s)
  • Create wallets for users
  • Link certification token to current certifications
  • Issue, validate and revoke certifications
  • Preserve privacy (certification status) of the grower
  • GDPR compliant
• Build application(s) for users
  • Build a front end application for a producer to check the certification status
    - Add notifications for outdated or revoked certificates
  • Build a front end application for a certification body to issue and revoke the certification for a specific grower
    - Link certification to a unique issued certificate
  • Build a front end application for the grower to get insight in the current status of certification, request re-certification.
• Deploy
  • Create deployment scripts
  • Deploy blockchain building blocks on test net (depends on the blockchain platform) o Deploy front end applications on test servers
  • Run tests

If working well, the developed application will serve as a base for further development with an extended network of growers, producer and certification bodies.

A previous student team analyzed this process with involved companies and created a Figma design for the applications. Written reports and video presentations of their work will also be made available for the future teams. This can be used by the student team as a starting point.

The Spark! Living Lab – Lab manager is available to support the team on a weekly basis

Deliverable: code, test cases, setup for the user test, report.

[stef-roos]

Making Blockchains Scale: A Framework for Novel Payment Channel Network Routing Protocols
Context: Payment channel networks drastically increase the throughput of blockchains. In contrast to legacy blockchains, they allow two parties to establish an off-chain channel with on-chain security guarantees. Using this off-chain channel, parties can conduct an arbitrary number of transactions without broadcasting them to the blockchain. Parties not sharing a direct off-chain channel can forward transactions via multiple channels[1]. Routing algorithms that choose the channels for forwarding are important to guarantee the success of payment channel networks. In the last year, three promising routing algorithms specific to payment channel networks were developed: Spider[2], Boomerang[3], and Interdimensional SpeedyMurmurs[4]. As they were developed concurrently, there is no meaningful comparison of the algorithms and it's unclear which one should be deployed in practice.

Task: In this project, you first review the implementations of Spider, Boomerang, and Interdimensional SpeedyMurmurs. You then define criteria a simulation framework for the evaluation of these algorithms has to fulfill (e.g., scalability, concurrency, realistic latencies). Based on these criteria, you choose a framework and implement the three algorithms (you may choose one of the frameworks used in the original evaluation). After verifying your implementation, you define suitable evaluation scenarios and metrics and compare the three algorithms for these scenarios and metrics.

References
[1] https://nms.kcl.ac.uk/patrick.mccorry/SoKoffchain.pdf
[2] https://dl.acm.org/doi/pdf/10.1145/3286062.3286067?casa_token=i0jkk4jxT6EAAAAA:56BPK5GWzglFfueZeEwrKe2RSJQy4n-AJGMixp3VK3JR_3XKT2GQbXLkqVflMtuaI49EwoSMEdo
[3] https://arxiv.org/pdf/1910.01834.pdf
[4] https://eprint.iacr.org/2020/555.pdf

[synctext]

Class of 2021 is adding the following to the Superapp:

• OPERATIONAL Federated machine learning the first AI dAPP - self-evolving AI-DAO #5987
• OPERATIONAL Multi-Signature Bitcoin wallet Bounty payout voting and payment execution - self-evolving AI-DAO #5986
• OPERATIONAL liquidity pool Euro-Bitcoin A Mobile and Generic Asset Exchange using Liquidity Pooling [group 2] #5996
• OPERATIONAL liquidity pool Bitcoin-Ethereum A Mobile and Generic Asset Exchange using Liquidity Pooling [group 1] #5988

[synctext]

(in)Stability status: