I’m Troels, Senior Blockchain Engineer. My work revolves around the ledger and I am building two teams at the moment. The first is the ledger team, they are responsible for implementing and maintaining our scalable ledger solution. The second team is our Virtual Machine team which is responsible for building the foundation of the our smart contracts and useful Proof-of-Work (µPoW).
The scalable ledger team is all about building a ledger where transactions are 1) communicated in parallel and 2) executed in parallel. Amongst other things, this requires a sharded state database and very fast transaction synchronization. Additionally, it also requires a transaction execution schedule to be generated. To accomplish these tasks the team has been building custom networking protocols with a strong focus on data serialization and communication together with the necessary architecture to scale a node across multiple processes. To get the transaction scheduling operating the team has built some amazing optimisation algorithms.
The VM team are building our smart contract and µPoW engine. The VM work is focused on two important aspects: 1) Modularity and customizability, and 2) linear algebra operations. The modularity is important as the Fetch ecosystem will need to deploy variations of the same engine. For instance, a VM inside an agent will need different functionality to the one that is evaluating the smart contracts. The linear algebra operations are important for a number of complicated decision making tasks. We anticipate that this will be important in our mission to make smart contracts truly smart.
The vision of the Fetch ledger is to create a framework that allows machines to reach agreements in order to meet common goals and empower distributed autonomous organisations. In a previous blog post, Josh spoke about how he wants to build an agent for himself to order milk from the milkman. Let’s explore this use case from the milkman’s perspective: As more and more people start to use the agent created by Josh, the milkman will become busy to the point that he or she can no longer serve the market single-handedly and therefore more milkmen will enter the market. The milkmen have one common goal: deliver as much milk as possible with the lowest possible operational cost. Traditionally, the milkmen would form a co-operative, but in a Fetch world milkmen would form a decentralised autonomous organisation where the rules of engagement are managed by smart contracts. This means the milkmen would write a smart contract that allows them to distribute work between each other. You could easily do this on Ethereum, but there is a catch; with an increasing amount of milkmen coming into the system, the contract runs into a scheduling problem. This problem cannot be solved with the current version of Ethereum and this is where the Fetch ledger shines. Inside of the Fetch ecosystem, the milkman scheduling problem is outsourced to miners who provides solutions. As with normal work in the Bitcoin protocol, miners propose solutions and the strongest one is selected. This allows us to include solutions to complex problems directly into smart contracts.
To illustrate the general kind of optimisation you can deploy on Fetch, let’s consider two milkmen doing 8 deliveries on a Manhattan geometry. Below we illustrate a suboptimal solution that would be obtained by a normal smart contract enabled ledger:
A normal ledger will have to schedule appointments as they come in rather than considering the wider context of the milk delivery. With the Fetch smart ledger this is different as we can outsource the optimisation problem and use the result to finalise agreement between the participants. This means that the end schedule would look like this:
As before, all the deliveries are made, but the individual on the green route has lowered his/her total travel by one block. This is a net economic gain as it decreases the average cost for the milkmen to do the same job.
I am really excited about this aspect of Fetch and the innovations that our teams have delivered to contribute to the Fetch vision. In the coming weeks and months I am really looking forward to seeing our teams putting the pieces together and evolving our internal testnet as we rapidly move towards the launch of the public testnet.