Datarella, together with leading industry partners and research facilities have been awarded a contract for the feasibility study titled “Collaborative Smart Services for Industrial Value Chains in Gaia-X (COSMIC-X)”, funded by the German Federal Ministry of Education and Research.
Building on the results of joint project KOSMoS, the goal of the two year project is to use the Gaia-X industry data space (IDS) for provisioning advanced smart services (ASS) in the context of spare part supply chain automation and optimization.
The target group of COSMIC-X are machine tool manufacturers, component suppliers and machine operators, with a special focus given to assisting small and medium-sized enterprises (SMEs) in taking part in and profiting off of the Gaia-X ecosystem. The specific use cases that will be explored in close collaboration with industry partners SW, HAWE und KROHNE are digital twins, trusted supply chains and platform-based maintenance.
With its expertise in blockchain technology and self-sovereign identity (SSI), Dataralla is tasked with defining the technical requirements of the use cases and, based on these, develop a blockchain-based system architecture in conformance with the Gaia-X framework. This will ensure an open, transparent and secure infrastructure for data sharing and collaboration.
We are looking forward to working on this project with all of our partners and will keep you updated on the results.
As part of a German consortium, Datarella has successfully finished the research project KOSMoS. KOSMoS was a joint research project aiming to build a collaborative smart contract platform for the digital value chain in the field of Industry 4.0. This research and development project was funded by the German Federal Ministry of Education and Research (BMBF) and managed by the Project Management Agency Karlsruhe (PTKA).
KOSMoS worked to develop a collaborative platform for small and medium-sized companies (SMEs) in the manufacturing sector based on distributed ledger technology (DLT). DLT is a family of innovative, decentralized technologies with blockchain technology being the most popular member of the family. Within the KOSMoS project, two different industrial use cases were realized on a DLT-based platform: 1) dynamic leasing, and 2) transparent maintenance.
The primary goal of KOSMoS was to develop a platform for the cross-company networking of production and process data using blockchain technology. The platform is able to integrate new offerings and business models. Examples include transparent maintenance concepts, dynamic leasing, and proof of quality for delivered products. Through these business models, all cooperating companies should gain an advantage. Examples of such improvements include lower prices, lower maintenance costs, and easier product distribution. In summary, the project should facilitate better cooperation amongst companies in the industry sector.
The Hyperledger Fabric DLT used in this project was part of the following logical system, where most of the individual components are accessible over standardized ports, and others were only available in private networks:
The final results of KOSMoS were presented at a full-day workshop in March including all three initiatives of the InKoWe association.
We from Datarella were very proud to be part of this innovative research project and happy to make a major contribution to the consortium with its DLT experience.
The German Environment Agency (UBA) commissioned the Frankfurt School Blockchain Center, Capgemini and Datarella to elaborate a feasibility study on the use of DLT in today’s emissions trading registries. Datarella is happy to announce its successful completion.
The aim was to evaluate whether the DLT is suited to efficiently represent the current European emissions trading system (EU ETS). The insights generated by the project partners will support policymakers in informed decision making with regards to the question of whether to remain with a traditional architecture or with a central relational database. For this purpose, the technical concept of an emissions trading DLT and the consideration of the efficiency and sustainability of an emissions trading DLT were explored. As a result, we were able to demonstrate how Emission Allowances can be represented on the blockchain. Hereby, the scope of an emissions trading system can be significantly expanded without extensively altering users’ current user experience .
As a key benefit, our DLT solution offers a robust infrastructure that is secure against manipulation attempts. Additionally, with DLT, well-known advantages such as transparency and traceability can be established in emission trading systems. Our concept also provides sustainable and energy-saving operability of a DLT-based emissions trading system.
The Frankfurt School Blockchain Center, as coordinator of the project, has contributed dedicated scientific blockchain expertise. Capgemini provided a rich set of expertise in carbon trading, registries, and private blockchain implementation. Datarella as a Web3 solution provider contributed comprehensive implementation expertise of enterprise blockchain solutions.
The result of the feasibility study was highly satisfactory for the client. In the future, the result will be presented to a larger circle of interested stakeholders.
In the last months, we have built the MVP of the Rohingya Archive, a digital heritage archive for the stateless Rohingya people. The R-Archive uses Arweave’s Blockweave technology to store documents immutable and permanently at very low costs. During our pilot phase, our partner, the Rohingya Project collected and uploaded various documents to preserve the Rohingya legacy. For detailed information on the pilot, checkout the pilot report here.
Feel invited to watch our demo, which will provide you more information on the background of the Rohingya Archive and its current features.
In this blog post, we look at the potential of service automation through autonomous economic agents in Blockchain-based systems. Datarella’s partner Fetch.ai has made it their mission to combine intelligent agents with blockchain technology in several use cases. Deep Parking is one of them, and using a specific example from MOBIX here you can get a feel for the potential of autonomous agents.
The path to the fourth industrial age is being paved by the interplay of Big Data-driven automation, robotics, IoT and Distributed Ledger Technologies, aka Blockchain. Given the increasing amount of data, and the number of digital services that go hand in hand with this progress, the need to automate them is also growing. Users should be relieved of unnecessary work and offered optimal results.
Agents take on the role of autonomously performing tasks on behalf of their clients (individuals or objects). For this purpose, they can also interact with each other. Intelligent agents can make complex decisions by using ML, i.e. AI-powered algorithms, based on large amounts of data.
A blockchain, with its data supply, offers a particularly favourable environment for intelligent agents. The data of a blockchain are permanently available and are logically related to each other. Decentralisation can offer robustness (no single point of failure) and lower transaction costs. Agents can assume a fully autonomous identity on a blockchain through private keys. They can use it to authenticate themselves and communicate their suitability for certain tasks. Agents can use shared protocols (possibly through smart contracts) to coordinate, collaborate efficiently, e.g. by distributing complex tasks among themselves. They can negotiate and make distributed decisions (even though voting processes use their blockchain). Tasks, goals or motives of agents can be recorded in the blockchain and economic incentives can be set for optimal task performance.
With regard to the IoT, a blockchain (as a single point of truth) can integrate various sub-systems, s.a. smart household appliances, smart buildings, smart districts and smart cities, and create added value for all agents participating in the network. Fetch.ai is an example of how intelligent agents can realize automated services based on blockchain technology.
Among the use cases of Fetch.ai, we would like to highlight agents for mobility services – traffic sign agents, parking agents for Deep Parking, agents for eMobility, agents for trains and stations that could even form a decentralised train network. In the process, increasingly intelligent autonomous agents interact on behalf of people or infrastructure, searching for each other, negotiating with each other in the interest of offering their users optimal solutions. In such a case, an autonomous agent of a car could, on behalf of its owner, seek and negotiate with agents working on behalf of parking lots to navigate the car and its owner to a quick and cheap place to park. With Deep Parking at the IAA in Munich 2021, the potential of agents for such use cases becomes clear.
There it was demonstrated how agents negotiate their resources on behalf of vehicles, their owners and the infrastructure to find an optimal solution for everyone without further efforts for the users. The following graphics show an excerpt from the exemplary communication between the agents involved.
In this case, a user named Jane is looking for available parking space in the city centre. Without Jane having to do this herself, the agent in her car (My Agent (Car)) looks for another agent who offers a parking space via a specific (agent-)network (SOEF). Using Blockchain technology, agents handle authentication, price negotiation, reservation and even payment, autonomously according to their client’s preferences. When Jane approaches the parking lot, access is automatically granted to her car without further ado.
As shown, the scope of tasks autonomous agents can perform and the added value they can contribute is without limits. So, by using autonomous agents, the potential of Blockchain technology can be leveraged for all use cases where handling of huge amounts of data in real-time or near-time is needed.
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!
Today, we trust Instagram, to keep track of our followers, likes, and chat histories. We trust banks, to document our balances and depots. We rely on Amazon, to maintain the lists of our past purchases. However, by trusting them we give up control and privacy. Slowly we are seeing adoption in Blockchain Technology as a decentralized and user-controlled trust machine. Similar to how banking software doesn’t keep track of your Instagram followers, it is likely that we will see a multi-chain future, in which use-case-specific blockchain networks are used to keep track of domain-specific states. Substrate by Parity Technologies allows for a first principle approach to creating these state machines.
Blockchain As State Machine
How much money did refugees spend in the markets of Jordanian refugee camps last month? #BuildingBlocks Which stakeholder within the long and complex humanitarian supply currently has custody of the emergency medical supplies? #Track&Trust Which parking credentials have been issued to my wallet, allowing me to park at the airport car park? #M-Zone Blockchain technology allows answering the above-stated questions in a trustless manner. Various components are required to allow individual participants of a decentralized computer network to reach an agreement over the state of a system. However, depending on the use case slightly different requirements arise for their underlying components. Some Blockchains need to be more secure, some faster, some more decentralized, some more private, and so on. Developing custom blockchains from scratch, with use-case optimized components, is very expensive. Imagine the costs for finding and bringing together experts of various computer science fields such as distributed databases, P2P networking, cryptography, and so on, to create a new Blockchain.
So wouldn’t it be great if there would a “Blockchain Kit”, which allows building custom, use-case optimized blockchain, using existing building blocks?
Substrate by Parity Technologies
And it turns out, there is Substrate by Parity Technologies, a modular and extensible framework for building blockchains from performant composable modules, called Pallets.
But let’s dive into the history of Party Technologies to get a better understanding of how Substrate evolved. Parity Technologies was founded by Dr Gavin Wood. Gavin is well known in the blockchain space for being the CTO and Co-Founder of Ethereum, cocreator of Ethereum’s Smart Contract programming language, Solidity, as well as its corresponding runtime environment, the Ethereum Virtual Machine (EVM). Since 2015 Parity Technologies built various blockchain clients, like parity Bitcoin, for Bitcoin (BTC) and Bitcoin Cash (BTH) mining, parity Zcash for the privacy blockchain Zcash, and OpenEthereum.
In 2017 Gavin published the Polkadot white paper stating the ambitions to create a heterogeneous multi-chain network, which connects various blockchains. During the development of the Polkadot Network, the engineers at Party Technologies noticed, that blockchains share many components and only some are unique. As a result, the Polkadot GitHub repo was forked to create a framework called Substrate.
So what is Substrate?
Substrate can be described as an open-source community, a modular software development framework, and a developer platform. The substrate framework allows the modular development of fast, secure, and socially scalable blockchains using substrate pallets.
1. Fast
Blockchains build on substrate reached up to 15k transactions per second.
2. Secure
The code of the framework is audited by top-tier blockchain auditing companies.
3. Socially Scalable
One major advantage of Blockchains build on the Substrate Framework is that they are upgradable without causing a hard fork. This is what’s meant by “socially Scaleable”. Hard forks are slow, inefficient, and costly since they require tremendous “cat herding” of node operators. Let’s take Bitcoin as an example. To update the network, the majority node operators, aka. Miners, need to be, first, convinced and, second, install the software update manually to their machines. In contrast, using Substrate, the business logic, which defines the behavior of a blockchain, is stored on-chain in the binary instruction format called WebAssembly, short Wasm. This allows automatically updating the whole network at a certain block height. So, let’s say some supervillain gets his hands on a Quantum Computer and you need to exchange the hashing algorithm of your blockchain for a quantum-proof one. The update can be done by sending a transaction. All the nodes will be updated automatically at a certain block height if they did not choose to leave the network.
The second benefit of using Wasm is that it can be run hardware-agnostic, which is a major benefit for node operators. Last but not least, Substrate Blockchains are interoperable with each other, as well as with other blockchain networks, like Ethereum, since they can be connected via the Polkadot Relay Chain.
4. Substrate Pallets
Substrate Pallets are the atomic building blocks of each Substrate Blockchain. A collection of pallets result in what is called runtime or simply the business logic of a blockchain. Each Pallet itself contains a domain-specific logic. The cool thing is, developers can discover, use and create Pallets on the Substrate Marketplace. Here are some Pallet examples from different categories you can use for building your own blockchain.
Category
Pallet
Accounts
Balances, for managing tokens
Recovery, social multi-sig recovery
Vesting, for looking tokens
Assets
(Non)-Fungible assets
Transfer
Destroy
Atomic Swaps, for exchange tokens
Consensus
Proof-of-Work
Aura (authority round)
BABE, slot-based block authoring with a known set of validates with on-chain randomness.
GRANDPA, finality gadget, if 2/3 of the GRANDPA authorities have voted for a particular block, it is considered final.
Governance
Democracy, for stakeholder voting
Election
Treasury
Identity
Superusers, which can remove accounts and slash balances
Smart Contracts
EVM, allowing for Ethereum compatible Smart Contracts
WASM, allowing fast, secure and efficient Smart Contracts
Conclusion
Substrate drastically reduces the costs of developing use-case optimized Blockchain infrastructure. Polkadot Network, which itself is mainly based on the substrate framework allows connecting these specialized blockchains, granting interoperability. Only time will tell how many Blockchains we will need in the end, but Substrate seems like a promising bridge to a decentralized state-keeping future.
The term “Token” is frequently used in the blockchain space. Shermin Voshmgir, the director of the Research Institute for Cryptoeconomics at the Vienna University of Economics, calls them even “the killer application of Blockchains“. This blog post aims to give you a better understanding of what a Token/Token Contract is.
A Token Contract is a special type of Smart Contract, which maps blockchain addresses to balances of value units – aka tokens. These software programs hold code, which specifies a set of functions and attributes of the value units, created and managed by the contract. Just like other Smart Contracts, Token Contracts are:
1. Censorship-resistant and Tamperproof
These computer programs are hosted on Smart Contract platforms, like Ethereum. Therefore, they are maintained and executed by all nodes of the blockchain network at the same time, which makes them censorship-resistant and tamperproof. Once they are deployed to the network, they cannot be changed.
2. Reactive
Smart contracts cannot initiate transactions themselves, they need to be called by an External Owned Account (EOA) or another Smart Contract. Therefore, they are mostly created by EOAs, which are controlled by private keys. However, Smart Contracts can send messages to call functions of other contracts, which allows creating a Smart Contract with another Smart Contract.
3. Controlled by their Code
Unlike EOAs, Smart Contracts do not have a private key. These programs are solely controlled by the code they hold in their persistent internal storage. Their code specifies functions, from which they can read and write to. Read functions: allow retrieving information from the contract, for example, the balanceOf(account) function, which allows reading the balance of a certain address, or the name() function, which provides the name of a token. Write functions: enable, surprise, to write new information to a Smart Contract. Most common is probably the transferFrom () function, which allows subtracting from the balance of the sender’s address and add to the balance of the recipient. Another interesting write function is mint(account, amount) which allows, when called, to create new tokens and send them to a specific address, respectively, the burn(account, amount) function, to destroy tokens. Calling these functions can be restricted, so that, for example, only the address which deployed the contract can call the mint() function.
Have a look at Etherescan to check out token contracts deployed to the Ethereum Blockchain. For example, the Smart Contract of the popular stable coin Tether (USDT). As you can see in the image below you can read from the contract, e.g. to see which addresses hold USDT or write to the contract to send tokens.
Types of Token Contracts
In general, you can differentiate between two major groups of token contracts by the properties of the value units they create and keep track of, fungible tokens and non-fungible tokens (NFTs).
1. Fungible Tokens
The value units of these smart contracts are interchangeable. Further, the Token Contract specifies the number of decimals – thus the divisibility of a token. For example, 1.000000 USDT is, divisible to six decimal places. However, one might argue that the fungibility of value units recorded on public blockchains is reduced if the transaction history is publicly available. For example, if certain tokens are sent from an address, which is known for being related to criminal activity, like a hack, they might not be accepted by exchanges anymore and therefore are not fully fungible. Therefore, only privacy tokens, like Monero (XMR), which transaction history is not traceable, can be seen as fully fungible. Another example of fungible value units created by Token Contracts, next to the monetary use case, are equal voting rights represented by tokens.
2. Non-fungible Token Contracts
These token contracts create unique – thus clearly distinguishable value units, which are not divisible. Each token created by such a program has a unique tokenID, which makes it identifiable. Non-fungible tokens (NFT) are often used to represent real-world assets, like art or real estate. Further, popular use cases for this token type are digital collectibles, like crypto kitties, digital art or digital land. Also, an interesting use case is Blockchain Domains, like Unstoppable Domains, which use NFTs to represent “.crypto” domains on the Ethereum blockchain.
ERC – Token Standards
With the rise of Ethereum, Token Contract Standards have been established, which enable wallet applications to hold and manage any type of tokens, complying with the standard. Therefore, the rise of standards allowed for great usability advancements. Ethereum’s standards are titled as “ERC” which stands for Ethereum Request for Comments and refers to a document that specifies rules Ethereum-based tokens must comply with.
ERC20 Standard
The most popular token standard is probably the ERC20, which creates fungible tokens, mostly used most initial coin offerings (ICOs). It is fairly easy to create an on ERC20 contract since it only requires a couple of lines of code. By today, over 333,500 ERC20 contracts are listed on Etherescan. These Smart Contracts have optional functions, like a Name, Symbol or Decimal, and 6 mandatory functions:
totalSupply()
Can be fixed or variable. If it is variable it can be calculated and return the total amount
balanceOf(address_owner)
Shows amount of tokens held by a provided address
approve()
Authorizes a contract to do something e.g. withdraw tokens
Similar like approve but checks for sufficient balance of an address
ERC721
The predominant standard for Non-Fungible Tokens is the ERC-721 standard. Over 7,500 contracts emitting this type of tokens are listed on Etherscan.
Popular tokens created by ERC-721 are, for example, digital football player cards of sorare, blockchain domains of unstoppable, and also the famous cryptokitties as mentioned above.
Conclusion
Token Contracts are computer programs, which create and manage value units and are deployed to Smart Contract Platforms. These code snippets are at-will programmable and can be designed to fit any kind of use case, from digital currency to collectible. Further, they can be programmed to create self-reinforcing positive feedback loops to bootstrap Web3 platforms and are the basis of any Token Economy. Stay tuned!
