Earlier this week, together with our partners at fetch.ai we released a driver walkthrough video that lets you come along for the ride during the M-Zone Field trials. For the first time, Datarella and Fetch.ai have field-tested an AI-powered Deep Parking solution installed at the Connex building complex in Munich. M-Zone provides automated incentives for efficient smart parking in metropolitan areas. It cuts C02 emissions by providing drivers with real-time options for parking and nudging them with tokenized incentives to park when and where demand is lowest without wasting time or energy driving in circles looking for a spot. Lots of people have asked for more details on how the system works so we decided to draft a technical deep-dive post explain how we built the system and what’s next for M-Zone.
First, let’s dive into a description of the hardware we used to make the M-Zone Smart Parking field trials possible. After that, we’ll delve into the software components and architecture as well as taking a look into how the fetch.ai agents interact with one another and what those interactions mean for cities, parking infrastructure providers, drivers, and the environment.
Edge Nodes
Two edge nodes powered up and scanning for plates. The display between them displays images captured during testing.
For the M-Zone field trials, we deployed two edge computers running computer vision software and fetch.ai autonomous economic agents to the Connex buildings at Frankfurter Ring 81 and 15. These edge computers have two main jobs. The first job is to monitor incoming and outgoing traffic and to read the license plates on incoming vehicles. The second job of the edge nodes is to keep track of the fill state of the parking lot and to publish data about available parking to their associated coordinator agent which is in turn registered on fetch.ai’s Simple Open Economic Framework.
Hardware
Compute: Raspberry Pi 4 Model B
Power: Uninterruptible Power Supply (Pi hat) and 1000 mAH Battery Pack
Connectivity: 4G router with OpenWrt
Cooling: Heat Sink with GPIO Risers and fans
Optional Video Output: 7” Display attached to casing with magnets
Enclosures: Waterproof aluminum boxes that have been modified for cable and camera routing as well as the addition of a plexiglass window for better LTE connectivity
Various USB A, C, and Micro HDMI cables for routing power and video
The hardware used in the field trials is based on cheap and ubiquitous raspberry pi computers and is intended to provide a plug and play upgrade to “dumb” parking infrastructure. Deployment is as simple as mounting the waterproof enclosures in a position where they have a good view of the entrances and exits of the parking garage allowing them to compute the fill level of the lot by observing the comings and goings of autos on a constant basis. Our computer vision solution uses the OpenALPR libraries to accomplish plate detection, edge recognition, binarization, deskewing, character segmentation, and finally optical character recognition to read out the license plates. This enables the nodes to authenticate autos on-the-fly. Future versions will contain a few hardware upgrade options include ruggedized custom enclosures and an improved embedded connectivity solution. The current version performed admirably and passed the field trial with flying colors.
Software Architecture
The real secret sauce doesn’t really come from the hardware though but rather through the software. One of the most critical design choices we made with M-Zone is to host all the cloud-based portions of the system using a Kubernetes cluster for orchestration. This design choice allows the Postgres database and our swagger API to be deployed in a distributed fashion, running on multiple pods within the cluster. This has multiple long term advantages.
It provides options for redundancy at the data state and application layers across multiple nodes located in multiple geographies and using multiple centralized and decentralized cloud/storage options simultaneously. Currently, our K8 cluster is hosted on an AWS EC2 instance but it could be hosted simultaneously across a number of infrastructures in the future. Another key benefit of this approach is the built-in ability to do auto-scaling the database to match load and available resources within the cluster. Building out the system for the M-Zone field trials would have been a lot easier if we had used a less elaborate traditional architecture without orchestration but we believe the investment will really pay off especially regarding the deployment of the IoT nodes. In our field trial, we only had to manage two parking agent nodes but we plan to scale the system and open source it so that such systems can be scaled to cover entire cities. At that scale, it becomes really critical to have an industrial orchestration system that allows you to deploy devices as fast as you can flash SD cards and then never touch them again. Our use of Kubernetes means that we can push updates to the nodes anytime we need to via an “over the air” 4G connection eliminating the need to interact with nodes physically once they’re deployed.
Your micro incentives and real-time parking lot states visualized.
Parking Agents: The parking agent is responsible for the edge processing. Each one runs as a fetch.aiautonomous economic agent inside a docker container running on a Kubernetes pod which is registered as part of the same cluster. The Parking Agents are responsible for identifying the autos that enter and exit the lot by their license plate and matching those plates against the accounts of registered drivers in a privacy-preserving manner. All the image data remains at the edge to eliminate any possibility for centralized malfeasance and prevents data siloization by design. You can check out our privacy design concept for M-Zone here.
Coordinator Agent: The coordinator registers as a service on fetch.ai’s search and discovery mechanism for autonomous economic agents (SOEF). This allows for the parking agents to find the coordinator. The agent also has responsibility for dynamically calculating the incentive payments due to the registered vehicles and executing these payments on the fetch.ai V2 Testnet. It also has the responsibility of periodically converting the issued V2 Testnet micro incentives into FET and sending settlement transactions out to wallet holders.
Settlement Wallet: We built a custom version of our XSC Smart Wallet to handle the receipt of FET settlement transactions.
Fetch V2 Testnet CLI Wallet & Account Visualization Web App: In order to handle the micro incentives on the Fetch V2 testnet we utilized a CLI wallet and visualized inputs from both our API and from the current wallet state to provide drivers with a real-time view of which parking lots have the most space and provide the best incentives.
Dashboard: Just for fun we also built a dashboard that provides an overview of the overall system. This is connected directly to the Postgres Database hosted within the cluster.
API: A swagger API provides the information consumed by the Account Visualization Web App.
High-Level Sequence Diagram
In the above sequence diagram, you can see that the Parking Agent edge nodes continually look for new images provided by our Kubernetes cluster. Next, they search for available agents on fetch.ai’s Open Economic Forum (OEF), the search and discovery mechanism for autonomous economic agents. The OEF returns the Coordinator Agent address to the Parking Agents after which the Parking Agents are able to register themselves with the coordinator. At that point, these agents start scanning for license plates. When they recognize the entry or exit of vehicles, they send a parking event to the Coordinator Agent which acts on the information by updating parking availability broadcast to the wallet via API and also dynamically adjusting the reward ratios and sending the rewards as needed (micro incentives & settlement transactions).
Parking Agent Skills
The parking agents are responsible for all the edge processing. License plate recognition is handled by the third-party library Open Alpr Upon agent instantiation. After the agent starts it performs an OEF search to locate the coordinator node. Once the agent has successfully located the coordinator agent, the agent sends an event packet to the coordinator agent. There are 2 types of events that parking agents can currently trigger.
Parking events: This event type provides information to link the entrance or exit of autos in the parking agent field of view to timestamps and map those autos to registered user addresses on the fetch blockchain.
Agent Update: This event type contains a status update from the parking agent. Within its main act function, the agent checks the most recent image saved from the raspberry camera. Any license plates are temporarily stored within the agent memory and deleted following processing. The size of the license plate detected relevant to the frame is also temporarily stored on the edge. Based on whether this frame size is increasing between snapshots or decreasing we can calculate whether a car is entering or exiting the garage. On each iteration, this memory bank is compared with the current image and if the agent detects a new plate, it sends an event update to the coordinator.
Coordinator Agent Skills
The coordinator registers as a service on the OEF which allows for the parking agents to find the coordinator. The agent also has responsibility for calculating the incentive payments due to the registered vehicles. Payments are incrementally made using the Fetchai v2 ledger due to low transaction costs and speed of settlement. Settlement payments are then periodically aggregated at a pre-determined interval to be batched and sent. Through this process, drivers receive payments of FET that are directly driven by their recent driving and parking behavior.
What’s the Economic Theory at Work?
Neoclassical economic models make a great of assumptions that often don’t hold up in the real world. Particularly under conditions of information asymmetry and in areas where public goods and externalities are present, “perfect competition” usually breaks down and inefficient markets are the outcome. This is what we currently observe in the parking market and it’s a big part of the reason why parking in cities is so annoying.
Public goods are defined as goods that are both non-excludable and non-rivalrous. Externalities are costs or benefits that are imposed on a third party who did not agree to incur that cost or benefit as part of an economic transaction. Market-based economies struggle to contain negative externalities like pollution and struggle to allocate public goods such as physical infrastructure because the assumptions of “perfect competition” don’t hold in the real world and markets don’t lead to efficient outcomes in the presence of these real-world issues.
At the risk of glossing over too much economic detail, essentially, in order for anything close to an efficient market for parking to exist, we need much better information. The M-Zone parking liquidity protocol is at its core a machine for improving market information levels and providing market participants on both the demand and supply sides of the parking equation with appropriate nudges to incentivize market participants toward more efficient market outcomes. The result is less CO2 emissions, better utilization of existing parking infrastructure, more efficient permitting processes and less time spent driving in circles looking for parking.
What’s Next for M-Zone Technically?
We’re currently in the process of defining the roadmap for building out M-Zone. The exact steps aren’t yet locked-in but there are some major topical areas that we can say are on the agenda.
Self Sovereign Identity-based Authentication
Payment gateways
Reservation pathways
Multichain search and discovery
Hardware “in the car”
More strategies for mobile agents and wallets
Improved UI and driver registration processes
Stay tuned over the next few months. There’s much more to come!
We’ve all been there. It seems like every time you go downtown you end up stuck in traffic and then have to drive in circles for ten minutes searching blindly for a parking spot. Even if you have one of the “digital” parking apps you can only park in a limited number of “in-network” spots. We think we’ve got a solution for this mess. In the video, above you’ll ride along with a real driver during one of our field tests leveraging fetch.ai autonomous economic agents and AI-enabled smart parking garages. Further down in this article we’ll examine the environmental, social, and technical aspects of our “M-Zone Parking Liquidity Protocol” approach to solving the parking riddle in cities.
Currently, Parking is Like Flying Half Empty Planes
Today, the vast majority of parking spaces in cities are locked up in various forms of reserved parking. Much of this capacity is reserved 100% of the time regardless of whether it is needed which leads to parking spaces sitting unoccupied mere meters away from where demand for parking is very high. High demand leads to more parking infrastructure being built. This in turn causes massive CO2 emissions for the building materials required (namely cement which requires 900 kg of CO2 per ton to produce). Cement is the source of about 8% of the world’s carbon dioxide (CO2) emissions. In addition drivers Just in Germany, drivers spend an average of 41 hours a year searching for the elusive parking spot at a cost of €896 per driver in wasted time, fuel, and emissions and the country as a whole €40.4 billion. One of our basic assumptions is that if parking infrastructure must be built it should be used as intensively and efficiently as possible to prevent additional unnecessary infrastructure from being constructed. For this to be possible we need intelligent parking systems that provide the correct incentives and nearly perfect information about usage without sacrificing privacy.
Most people wouldn’t compare parking infrastructure to airplanes but it’s actually a relatively good comparison. We all know that aviation is a major contributor to C02 emissions and airlines make every effort to ensure that every flight is as full as possible including “codesharing” where two airlines sell tickets on the same plane to ensure the flight doesn’t fly empty. They also use dynamic pricing to alter customers’ demand curves for particular flights at a particular time and price. What we’re proposing is analogous in the world of parking. Currently, the world of parking could be compared to flying all the planes half empty all the time and adding more capacity constantly despite increasing costs and environmental impact.
In this context, we can define waste as being any time that parking spaces are empty despite there being demand for those spots. Our Parking Liquidity Protocol allows us to recycle already existing capacity to meet current and future expected demand for parking instead of building new parking infrastructure and capacity.
Bringing the Vision of a Parking Liquidity Protocol to Life
Parking lots need to become aware of their full state and become able to communicate their fill state to users directly over a mobile wallet app AND to automatically incentivize these users to drive and park less by rewarding behaviors that are more sustainable. This vision led us to leverage the fetch.ai blockchain. The fetch blockchain includes “autonomous economic agents” which are essentially AI-powered programs that make economic decisions on behalf of users or machines and then execute economic transactions without human intervention on the blockchain. In partnership with the fetch.ai team, we conceived and built a number of edge computing devices with integrated uninterruptable power supplies, 4G modems for connectivity, and high-resolution cameras that can be deployed quickly and easily at parking garage entrances and exits.
Here we’re preparing the Autonomous Economic Agents for deployment on-site at the Connex buildings.
These edge computing devices (raspberry pi – based) are running computer vision algorithms that allow them to identify license plates on incoming and outgoing vehicles and to calculate how full the parking lot itself is. They are networked together with one another and with a “coordinator” agent which aggregates the information from daughter nodes and determines dynamically which micro-incentives should be sent to any individual driver at any one time. We’ve also built a web app that allows drivers to see the fill status of the lots how much their earned micro incentives, reward rate, and how much this earning rate will be reduced by parking in a particular lot at a particular time. Not parking at all is rewarded most but parking where and when parking demand is low also gets some rewards. Last but not least there is a settlement layer that sums up the micro-incentives that a driver has earned through parking less and parking more efficiently and makes payments in FET tokens to the driver wallet. These tokens are tradeable on the open market and are directly exchangeable for Euros or USD. It goes without saying that privacy by design is at the core of our system architechture.
Critically, these edge nodes are managed by a Kubernetes-based container orchestration system which allows us to do over-the-air updates to the hardware without retrieving it from the field. This greatly increases the scalability of our system because it allows us to install the hardware which provides intelligence to the parking garages once and never touch it again unless physical maintenance is required.
A two-node system has been field-tested successfully at the Connex building complex in Munich. These buildings are owned by Datarella Partner Hammer AG with whom we ready partnered to execute one of the first regulatory-compliant real estate tokenization projects last year (ConnexCoin). The money for the driver micro-incentives comes from the savings of both commercial real estate developers like Hammer AG and their tenants. Now with our system, they have the means to share parking capacity across nearby buildings. Hammer AG alone has 5 buildings on the same street in Munich within the Connex complex so it’s really realistic to encourage drivers to distribute parking load across the neighborhood and walk a few minutes further to reach their end destination.
What’s next?
We’ve got a lot on our plate for the next months. We’re looking to build on the success of the field trials to augment the parking liquidity protocol with a bunch of new components. We’re working on integrating a self-sovereign identity framework to beef up the privacy of our authentication methods. Parallel to this, we’re building out the user interfaces and onboarding processes working with our partners to expand the M-Zone parking liquidity protocol for payment and reservation. On top of that, we’re designing an open protocol tech stack to enable the search and discovery of parking lot ID’s and states in a chain agnostic manner. Keep an eye out for a technical deep dive in the coming days where we’ll get into the nitty-gritty of how the system works!
When people start talking about blockchain they often mix up the security models with consensus algorithms. If you’ve ever scratched your head when these terms start getting thrown, around this post is for you.
Every IT system has some type of security model. Security models answer the question, “how will this system grant access to “good” actors and limit the damage that “bad” actors can do”. In the traditional world of networked computing, this is often achieved through a role-based access control (RBAC) model. Typically these systems rely on establishing shared communal trust in a trusted certificate authority and X.509 certificates.
The internet domain name system is somewhat more complex but follows this basic paradigm with the Internet Corporation for Assigned Names and Numbers (ICANN) being responsible for the central issuance of certificates that enable your browser to resolve human-readable internet addresses. As with Blockchain systems here, governance is key to the functioning of the security model. There are many other types of centralized security which are regularly used for military command and control systems as well as access control for civilian infrastructure.
As you can see, these are large categories that describe how access control is organized and how computer systems in the system arrive at their individual or collective states. These models do not however stipulate the specific technologies or algorithms to be used. Proof-of-Work, Proof-of-Stake, and Proof-of-Authority are types of security models, not actually consensus algorithms.
Consensus Algorithms Enabling Blockchains with a Proof-of-Work Security Model:
There are at least half a dozen popular implementations of consensus algorithms that utilize a PoW model. Check out this post from Jan Vermuelen to learn more about the varieties of PoW algorithms. The main thing that changes between these algorithms is the Hashing algorithm that they rely upon. Usually, the algorithms are named after the hashing algorithm they employ.
Although PoS, PoW, and PoA are the primary security models in the blockchain space there’s no limit on the type of security models that is possible and each of the security models has dozens of different implementations (and hybrids).
People in the blockchain space often throw around the words Byzantine Fault Tolerant (BFT) as though it was self-explanatory. Additionally, BFT often pops up in discussions about consensus mechanisms. If you look closer, in the consensus algorithm space there are lots of variants. there’s pBFT, Tendermint BFT, BFT Raft, IBFT, and Lisk BFT to name just a few. This short post seeks to clear up the confusion.
Let’s start with what BFT isn’t. BFT, or Byzantine Fault Tolerance is not a consensus method. It is not a security model. It is not a specific technology. It is not exclusive to blockchain or exclusively useful in blockchain systems.
A system can be described as Byzantine Fault Tolerant if it provides a method for solving the byzantine general’s problem. This is a problem in computer science wherein, the system handles malfunctioning or unreliable components that give conflicting information to different parts of the system.
This situation can be expressed abstractly in terms of a group of generals of the Byzantine army camped with their troops around an enemy city. Communicating only by messenger, the generals must agree upon a common battle plan. However, one or more of them may be traitors who will try to confuse the others. The problem is to find an algorithm to ensure that the loyal generals will reach agreement.
Byzantine Fault Tolerant, is at its core, a term that works as an adjective, and which as we have seen is often integrated into the names of various technologies to describe what they do. Any technology or system that has mechanisms for disregarding unreliable inputs from dishonest participants and reliably agreeing on a global state with only valid inputs from honest players can be seen as Byzantine Fault Tolerant. As such there are many security models and consensus algorithms that can be said to be Byzantine Fault Tolerant.
Additionally, underlining the fact that BFT isn’t a security model or blockchain specific consensus algorithm, BFT architectures are commonly used in military command and control as well as spaceflight and aircraft control systems. Two prominent real-life examples of BFT systems outside the blockchain space include the ARINC 659 SAFEbus network used for flight control on the Boeing 777 and 787 aircraft and SpaceX Dragon Capsule systems for approaching the International Space Station in case of multiple computer failures.
You may have heard people in the blockchain space throwing the term Inter-Blockchain Communication or IBC around lately. This term refers to any technology that allows transactions across multiple blockchains.
It’s not that simple though. There are actually two sub-categories of cross-chain transactions that need to be differentiated.
Homogeneous IBC: transactions across two different operating on the same core protocol.
Heterogeneous IBC: transactions across two different chains on different core protocols.
This is really a rabbit hole! What’s a core protocol? Essentially if two chains share the same core protocol which can natively verify and utilize the state of another blockchain using that core protocol. This is more complex than it appears at first glance.
Homogeneous IBC:
In chains such as Cosmos, all have different security models and do not all share the same consensus mechanism. Despite this, all Cosmos Blockchains are compatible with the inter-blockchain communication protocol which provides “reliable & secure inter-module communication between deterministic processes that running on independent distributed ledgers”. Additionally in chains such as Polkodot there IS a shared security module. In that case, a relay chain makes it possible for state changes on one Polkodot “parachain” to be ingested by and compatible with another parachain.
Heterogeneous IBC:
Most Blockchain ecosystems that offer Homogeneous IBC between chains operating on the same core protocol also offer some possibility for interacting with external chains that are “economically and technically sovereign”. In the case of Polkodot these chains are called Bridges. The Cosmos ecosystem uses a functionality called the “peg zone” to enable Heterogeneous IBC.
An in-depth discussion of how these functionalities work deserves its own post.
People often ask us if our our blockchain solutions are energy efficient.There’s a lot of articles and good research out there indicating that the most famous blockchain, Bitcoin, uses as much energy per year as a small country. Let’s take a quick look at the myths and the reality in industrial settings.
The Myth: “All blockchains use large quantities of energy.”
The Reality: All blockchains DO NOT use large quantities of energy. Not all blockchains are the same and not all use cases require the same “blockchain”.
Bitcoin uses a consensus mechanism known as Proof-of-Work (PoW) to secure the network. While this approach has some advantages, there are other options for both, private and public blockchains, which don’t cost significant energy and still result in a secure network. For industry, it usually makes sense to utilize a private consortium blockchain with Proof-of-Authority (PoA) validators operated by consortium members. This approach effectively cuts the electrical consumption to almost zero. The level of decentralization, trustlessness and security that Bitcoin provides is way over the top for the vast majority of practical blockchain applications in industrial settings.
Additionally, even in situations where a public permissionless system is needed, there are a myriad of options regarding the choice of consensus algorithms which don’t consume exorbitant amounts of energy. Modern Proof-of-Stake (PoS) systems secure the network by requiring network validators to put up a “stake” (i.e. reserve) of tokens which can be automatically taken away or “slashed” if validator nodes attempt to cheat the system.
Bottom line: energy consumption isn’t an issue for us when working with industry partners. Consider the myth debunked.
In his 1901 published article titled “The Scope of Social Technology“, Charles Henderson renamed social art as ‘social technology’, and described it as ‘a system of conscious and purposeful organization of persons in which every actual, natural social organization finds its true place, and all factors in harmony cooperate to realize an increasing aggregate and better proportions of the “health, wealth, beauty, knowledge, sociability, and rightness” desires.’
Later, the term social technology was given a wider meaning in the works of Ernest Burgess and Thomas D. Eliot,, who defined social technology to include the application, particularly in social work, of techniques developed by psychology and other social sciences.
As a result of its decentralised architecture, its openness, and its data immutability, Blockchain can be regarded as a social technology: New governance models, represented in DAOs and DSAOs, have demonstrated the social impact of Blockchain technology.
Datarella demoed a new PoC for off-chain governance with our friends from tyntec at the TADSummit in Lisbon, Portugal this week. Using tyntec’s 2FA service we were able to demonstrate a proof of concept for using strong authenication to secure an Ethereum transaction. This is one elementary piece of the puzzle for creating robust governance structures for the blockchain.
What’s blocking the blockchain from going mainstream? Datarella and tyntec at TADSummit Lisbon 2018
One of the main issues holding back adoption of blockchain-based applications is that we’re still at a pretty basic level when it comes to governance. Much ink has been spilled over the parity multisig wallet bug and the hack of the DAO. The exact causes of those incidents are beyond the scope of this article but both have to do with complexity and with finality.
One of the major selling points of Ethereum it utilizes the solidity programming language, which is Turing complete. This is both a blessing and a curse. It’s a blessing because this makes it technically possible to build very complex smart contracts which are capable of doing just about anything – that’s a big part of the promise of blockchain. The curse part of the equation is the fact that these complex programs may have unforseen bugs which end up irrevocably committing transactions on a large scale to public blockchains. This is where finality comes into play. Once approved Ethereum transactions are subject to increasing probabilistic finality.
In layman’s terms this means that there are no chargebacks, no refunds, no do overs and no room for error. The combination of complexity and probabilistic finality means that if we want to build blockchain applications that are ready for mass adoption we will need significantly improved safeguards and governance before transactions are committed to the blockchain.
In order to be useful, systems that transfer value have to exhibit some kind of finality. When you use a credit card to purchase a latte at your local store the money is transferred on a centralized ledger maintained by visa or mastercard. The money stays transferred unless there is a dispute. If you discover fraudulent charges on your card you just call your bank and prove your identity. They roll back the charges on your account and an insurer takes care of the damage done. In other words, in the credit card system, finality is limited but sufficient and flexible. In the blockchain world what you commit to the chain remains on the chain. If you loose your private key or a bug in some complex code allows an unintended value transfer, it’s game over.
We can’t change the finality of blockchain and in most public cases we don’t want to. What would be nice is if we could put additonal controls on what the holder of a private key can do. This is useful as a component of our developing blockchain governance toolkit in a number of situations.
Some example use cases:
Resetting access to a wallet
Restricting malicous transaction attempts
Enabling multiparty quorum transactions without relying on complex on-chain multisig wallets
Off-chain voting mechanisms
Take a look at the video of the demo above. What we’ve implemented is a smart contract which requires a one time password provided by the tyntec 2FA API in addition to the private key before any transaction can be finalized on-chain. This opens the door to all sorts of governace options which we’re working on for our product RAAY and as part of the Codelegit arbitration libraries which we provide to the Blockchain Arbitration Forum.
We’d like to thank the awesome team of tyntec for their continuing collaboration on this. We’re really looking forward to the role such tech can play in moving blockchain-based governance procedures forward.
The Blockchained Mobility Hackathon on the weekend of July 20-22 saw a flurry of innovation by a colorful mix of corporate and independent hackers along with some of the world’s biggest mobility players. In order to visualize the PoCs presented, we’ve built an interactive infographic.
Building a blockchain mobility ecosystem with multiple distributed ledger technologies is a complex task that will require the smartest minds among us over a number of years. To that end, we asked each of the hacker teams competing at the Blockchained Mobility Hackathon to locate their prototype within a specific point in the tech stack as part of a future mobility user journey. In the infographic above, you can click to explore each of the PoCs presented and see immediately where the solution fits into the big picture for blockchained mobility.
Embedded in the infographic you’ll also find the results for each team including videos of the final pitches, team interviews about next steps and you can even drill down into the code with direct access to the repositories from each team. Click the image now to expand the infographic and navigate to detailed information about each teams results.
We’re working hard to move toward the development of a mobility future where everyone can compete and collaborate by leveraging blockchain and distributed ledger technology across the mobility industry. Thank you to all of the participants and sponsors of the Blockchained Mobility Hackathon 2018! This is just the beginning.
