Technical solution

This section will show how BlockFood will be implemented. It will describe a technical overview of the solution, along with details on smart contract lifecycle and some technical aspects of how BlockFood will interact with smart contracts.

This plan is mostly an overview of what we foresee as needed for the platform to work, both technically and conceptually. Please note that every aspect of the technical solution is subject to potential changes during implementation.

Architecture

Overview

All users will access the platform using BlockFood Applications, with two declinations: mobile application and web application. Those front end interfaces will interact with the platform using BlockFood API, which will handle all aspects of the core of the platform (users, content, administration, …).

The API will communicate with dedicated micro-services: Blockchain workers service and Wallet service.

Blockchain workers will handle the communication with the Ethereum blockchain, using a specific mechanism described further in this document.

The Wallet service will have the responsibility to handle all wallets from the platforms users.

The platform will also be accessible to third parties to create alternative applications.

BlockFood Applications

Every actors accessing the platform will access it either through the official BlockFood applications or with any alternative applications developed by third-parties (see the "Third-party developers" below).

The BlockFood applications will be available:

  • Mobile-platform dedicated applications: iOS, Android
  • Web application accessible through a web browser on any platform

All BlockFood applications will share most of their logic and visual components using modern front-end development techniques.

See the "Features" section below for more information on the content of the applications.

BlockFood API

The BlockFood API is at the heart of the BlockFood platform. It is the crucial link between any application from the ecosystem and the Ethereum BlockChain.

It will handle every objects and methods of the BlockFood platforms: users, restaurants, menus, couriers, localization, transaction entry point, security, …

Scalability and availability are important characteristics for the API. It will be built with these characteristics in mind, using modern on-the-fly deployment strategies with scalable containers. Most API components will be stateless in order to achieve maximum simplicity and resilience.

BlockFood Wallet

A key aspect of BlockFood platform is to ease the use of crypto currency for all of its users. While the whole smart contract system will be usable without BlockFood Wallet, an integrated wallet will be offered to BlockFood user to simplify their interactions with the pltaform.

Security in a wallet system is crucial and it will be the main preoccupation while building BlockFood wallet. To achieve maximum security, BlockFood will not be able to access wallet without the user passphrase.

The benefit is to keep the wallet close to the user while preserving security. The downside of this solution is that because we will not store the passphrase the wallet can be lost if the user forgets its passphrase.

BlockFood Blockchain workers

The BlockChain workers service will act as an interface with the Ethereum blockchain, dedicated to the interactions with BlockFood smart contracts. They will help the rest of the system to keep track of smart contracts updates.

The service will implement a smart contract settlement layer to speed up Blockchain interaction. This mechanism is described in the "Smart contract settlement layer" section of this document.

Third-party developers

One core value of the Open Sharing Economy foundation is its openness. Opening our platform to external services is important in this aspect. Most current companies have closed the boundaries of their system in order to control it and keep their users locked.

We believe competition in the application area is crucial. It pushes ideas to their maximum and encourages all actors to give their best to give users the best possible experience. But unfortunately, every closed system that have locked their users slows evolution down which in the end, impacts the users negatively.

Third-party developers will be given the opportunity to create innovative applications relying on the BlockFood platform, by being able to use BlockFood API for free.

This could lead, for instance, to:

  • Local applications: country-specific, city-specific, …
  • Diet-specific applications: gluten-free, vegan, meat-lover, kosher, halal, …
  • Event-dedicated applications: conferences, competitions, meet-up, …

Once the BlockFood API reaches a maturation point in production, a contest will be organized to encourage developers to innovate by creating the most creative applications.

Smart contract architecture

Smart contracts are at the heart of the BlockFood project. Smart contracts are secured and tamperproof and they will be used as a blockchain-encoded medium for monetary interactions between the users.

This section will describe the different steps of a smart contract during an order and a mechanism that will allow to use them faster.

Smart contract overview

The decentralization of the BlockFood platform relies on the use of smart contracts. The goal of the smart contract is to act as an automated referee to customers, restaurants and couriers. It allows the transactions to be verified and secured without the need of a third party.

While BlockFood will ease the use of the smart contracts and will still be a centralization point for some information used in the platform, the smart contracts will be completely open and anyone will be able to create them without BlockFood interference. The openness of the API will ensure this independence.

The smart contracts will have the following lifecycle:

  1. Create order: a customer selects a restaurant, a courier and some items from the restaurant. The contract has to be created with the correct amount of BFT for the order to be valid. At this point, the smart contract holds all the information in order for the restaurant to be aware that a valid order has been issued.
  2. New order: the restaurant receives an event that a new order was created.
  3. Accept order: the restaurant can accept the order and issue an estimate of preparation time.
  4. Order ready:
    • Once the order is ready, the restaurant validates the completion.
    • The courier is then notified.
  5. Pick-up order: the courier picks up the order and calls a specific function from the smart contract to prove his identity and ensure the courier met the restaurant.
  6. Order delivered: the courier delivers the order to the customer and calls another specific function from the smart contract giving information that proves the courier met the customer.
  7. Order finalized: once the "order delivered" function has been called, the smart contract enters the "order finalized" state which will signal the completion of the order. At this point the smart contract initially loaded with BFT redistributes all BFT to the actors: the restaurant, the courier, the BlockFood platform and the BlockFood ambassador.

The smart contract described here is a simplified version with only the nominal path. Many pitfalls will be identified during the beta test period and BlockFood will address them promptly.

Smart contract settlement layer

The Ethereum networks requires a new block to be created to store a change in the state of a smart contract, which takes on average 14.67 seconds as of today (2017/11/28 - https://ethstats.net/). Since time interactions between actors must be minimized, waiting for the next block will not always be acceptable. This layer will speed up transactions while keeping the blockchain as the final authority.

The smart contract settlement layer will be used as an interface to speed up the smart contract state update, by acting as a light client of the Ethereum blockchain and focusing on BlockFood smart contracts.

If the smart contract function call is supposed to be a success, the settlement layer acknowledges the success and returns it under a second. If the actual call to the smart contract failed even though it should have succeeded, then an error event is raised. Otherwise a confirmation event is triggered since the smart contracts behaved as predicted.

To prevent security issues, every call to the settlement layer must be signed using user private key, as it would have been on the blockchain. Double calls will be made impossible with a fixed limitation of the number of calls between blocks.

Smart contract settlement layer illustration