PIP: 7774
Title: A Platform for the Rapid Development and Secure Deployment of User-Friendly Decentralized Applications
Authors: Nathan Hourt <nathan@followmyvote.com>
Status: Draft
Type: Informational
Created: 20-08-16
Abstract
This PIP describes Follow My Vote's proposal of a decentralized application application platform which provides supporting technology and guidelines for the development and deployment of blockchain-based applications. This platform is intended to make decentralized applications easier for non-technical users to understand, to secure these applications to the same standards as the blockchain itself, and to reduce costs and accelerate the development of these applications.
The platform will be built of a dApp browser that runs on user devices, and a services network. The platform will be designed to be able to integrate with many blockchains, but is expected to launch on Peerplays initially.
Context and Motivation
Since their inception, blockchains have shown promise as potential solution strategies for a vast range of complex societal problems, as well as opening the door to powerful new financial and contract applications which were infeasible with previous technology due to questions of honesty or fairness; however, the industry has had difficulty delivering on these promises without making compromises which are unacceptable for high sensitivity application domains such as those involving reputation or finance. This has led Follow My Vote to examine the situation in an attempt to understand why, although blockchain is so promising, uncompromising solutions have not so far been forthcoming.
The creation of user-friendly, effective blockchain applications is difficult for two main reasons. First, blockchain databases are controlled by complex and rigid protocols controlling the state of the system and updates to this state; however, these databases are useful only inasmuch as they can be used by laypeople who do not understand the protocols and do not naturally think in the same way as the protocols operate. Second, these databases are stored and tracked by servers, but the people whom they are intended to benefit are distant from those servers, interacting from either desktop computers or mobile devices.
In order to make these systems helpful to people, it is necessary to create an adaptive layer of software which deals with the relevant topics in a manner cognizable to humans and translating this human interaction into the formal protocols which control the data. This adaptive layer, known as the application software, necessarily runs on user devices rather than on the secured server systems, and constitutes the user’s only point of contact with those back-end systems and the data they track.
The application layer is the source of most of the difficulty in creating viable solutions to the problems blockchains should excel at. Although creating smart contract back-ends on the servers requires advanced skills, the industry has been largely successful in creating these solutions. On the other hand, the human-facing applications for these contracts, although being simpler technologically and requiring less advanced skills to craft, consume far greater resources and timelines to create, while the end result frequently leaves non-technical users confused or frustrated.
Compounding this issue, blockchain applications are largely built upon technologies originating in the pre-blockchain era that are not secured to the advanced standards of the blockchain protocols themselves. While this may be suitably adequate for CryptoKitties, applications with real world implications must be secured against all threats, and relying on architecturally insecure, legacy technology is unacceptable in these domains. To illustrate this point, consider an application based upon these lower standards. This application could be compromised in order to manipulate the information displayed to, or received from, the user, to act falsely on the user's behalf, or possibly even to detach the application from the legitimate blockchain back-end altogether. The user would be unable to detect this tampering without utilizing advanced technical skills.
In order to provide solutions to the sensitive problems that blockchain can address, applications must be developed to be naturally understandable to the humans using them, and must be deployed and operated upon technological underpinnings which are as secure as the decentralized back-ends themselves.
At present, however, no platform exists to provide for the full scope of the development, deployment to user devices, and executional operations of decentralized applications. Blockchains themselves are merely smart contract platforms; they are not decentralized application platforms, and the technologies
typically used to support blockchain-based application deployment are based on the world-wide web and do not embody security standards on par with the blockchain.
A new kind of solution is required; not a new blockchain, but rather a decentralized application platform that operates on the user's device, designed to protect the user's keys, reputation, and privacy, by loading and verifying decentralized application code using only protocols secured to the same standards as the blockchain back-ends themselves, and then providing those applications with a secure environment featuring powerful tools to enable the application to easily utilize advanced technologies to empower the user to act and interact online safely and with confidence that not only is their technology rigorously secure and working for no-one but them, but also that they fully understand its capabilities and the effects their actions will have.
Rationale
The decentralized application (dApp) platform is intended not only to secure dApp deployment and operations, but to facilitate the creation of user-friendlier dApps with shorter timelines and smaller budgets and better developer experiences than even the web can offer. To accomplish this inimitable goal, the platform will be not only a set of supporting technologies, but also a system of guidelines, documentation, and examples to ensure that the technologies are easy to use properly and difficult to use improperly.
Follow My Vote has selected several design goals to inform the design of the platform. First, the platform and documentation must be designed to ensure that developers can easily create applications which non-technical users will understand naturally.
Second, the platform must feature rigorous security standards, ensuring that application code is cryptographically authenticated before it is executed, and implementing developer-friendly APIs for the application to perform standard operations, such as network connections, with full authentication and encryption. All security protocols must function without reliance on centrally trusted providers; in instances where a degree of trust is necessary, the protocols must distribute this trust among several providers such that all providers should agree and therefore erroneous responses can be detected.
Third, the platform should emphasize dynamic rather than static infrastructure. Much of distributed software today utilizes what may be referred to as "static" infrastructure, where remote data and servers are located by URLs, IP addresses, and domains which indicate where the desired resource can be found. In these systems, whatever resource is found in the specified location is typically assumed to be valid without further verification. The platform should provide easy models for dynamic infrastructure, where desired resources are specified not by location, but by content: data is referenced by hash, and servers are referenced by public key. Thus, embedded within the app is the necessary information to recognize the correct resource when it is located, and the platform provides protocols to dynamically locate and verify the desired resource on-demand.
Finally, the platform must provide APIs that are easy for developers to understand and use correctly, along with documentation and examples covering their proper usage, so that applications can be developed easily with minimal time to market.
Specification
Current blockchain applications are developed and deployed using legacy web technologies with inadequate library support for the concerns universal to smart contract user interfaces. This results in the technical realities of the underlying blockchain protocols showing through the app to the user, causing confusion and frustration for non-technical users who are not familiar with the protocols governing blockchain systems.
To alleviate these problems, a dApp platform is proposed which facilitates the development of decentralized applications, and the secure deployment of these applications on user devices. At a technological level, the platform will be comprised of a dApp browser and a services network.
The dApp browser will run on the user device and provide a similar function to a web browser, but will use only technologies and protocols which secure the applications on the user device to the same level as the blockchain databases which underlie them. The browser will implement APIs to provide critical functionality to apps so that easy-to-use apps can be developed quickly and easily.
Platform Functionality
The platform will provide functionalities to accelerate application development while making it easy to create applications that make sense to users not already familiar with blockchain protocols. These usability functionalities include identity and key management, database caching, transaction management and modeling, and non-technical documentation of user interface controls and symbols. Issues surrounding these topics are common to most or all dApps, and to address them properly, technological solutions must be innovated.
Other functionalities are necessary to secure the deployment and operations of decentralized applications on user devices. These functionalities include secure queries of blockchain APIs, simple APIs for essential cryptographic operations, application code retrieval and verification, and network connection establishment and authentication.
Finally, some technologies are included to push the blockchain industry forward in places it is currently struggling. These include protocols for off-chain data storage, and infrastructure supporting user-to-user network connections.
Each of these critical functionalities will now be examined in greater detail.
Identity and Key Management
One of the most fundamental concerns in any multi-user software system is authentication. Historically, systems have addressed this concern via username and password pairs, and although few users tend to favor the password concept and the paradigm yields a generally weak security model, the password is familiar to most users, and thus the solution works, even if few people still believe it is a good one.
Blockchains, however, do not use passwords as an authentication mechanism, instead relying on cryptographic key pairs. This technology is unfamiliar to non-technical users, and thus simple user interfaces must be created to enable such users to interact with the blockchain. These interfaces should be provided without disenfranchising advanced users, however, who are familiarized with key management and wish to secure their keys according to their own standards.
Therefore, the platform should provide a simple and effective key management system which non-technical users can easily utilize, but simultaneously it should seamlessly integrate with popular
external wallet applications where possible, and it should also be possible to utilize custom or unrecognized key handling solutions if an advanced user wishes to do so. All of these key management strategies should be exposed to applications via a consistent, well-documented, and easily used API.
Database Caching
In order for applications to operate in any networked software system, the user application must have access to shared data and must be able to store some of that data in a local cache for display and modification. While myriad solutions for this may exist in standard client-server environments, these solutions typically require greater support from the server than is typically available in blockchain systems. In these systems, applications are required to operate with basic data query and subscription APIs, or else rely on off-chain data storage servers which degrade the trust model and increase the system’s attack surface.
The platform should provide chain-specific solutions for sparse data caching and offer reasonable strategies for tracking and maintaining the freshness of the cached data.
Transaction Management and Modeling
All updates to shared data in blockchain databases are processed via irreversible transactions. This model of access control is alien to incoming users, as most client-server software systems allow users direct and arbitrary modification of data on demand.
As a result, blockchain applications must cache local changes to the data in order to show the user an updated view of the system. When the user wishes to commit their changes, the application must sign and broadcast the transaction and track its status until it is confirmed.
To ensure that the front-end and back-end can be developed and upgraded in synchronization, blockchain applications should internally model their local changes as draft transactions which are applied to the local database cache. The application should also monitor the back-end for unexpected or conflicting changes
and notify the user if their desired actions are no longer possible.
The platform should provide mechanisms for applications to define their custom transaction types and implied modifications to the database cache, as well as track the status of local edits to cached data, so that applications can always show users a system state that is up-to-date and includes the user’s draft changes.
Interface Documentation
Even well-designed user interfaces are often confusing to new users, and in many cases, interface controls and symbols are ambiguous as to their exact purpose. Applications controlling highly sensitive data should go the extra mile to ensure that users can understand and predict what effect their actions will have before making irreversible changes.
While the transaction model of changes does help with this effect, there is still room for improvement by adding clear, non-technical documentation of the symbols and controls of the user interface.
The platform should offer a standard for applications to define documentation text describing clearly and unambiguously what UI controls do and what symbols mean. The platform should allow users to "inspect" a UI to access this information. Guidelines on how to write this documentation well should be provided so that developers can create high quality documentation which yields a tangible benefit to users.
Secure Blockchain API Queries
Whereas in traditional client-server computing, a trusted server provides the single source of information about the status of shared data, in blockchain systems there are typically many nodes available hosting the system state for query, and all of these nodes should give identical responses to any given query.
The platform should provide a simple API for querying these servers and should allow tunable security requirements to define the number of agreeing responses which are required to validate a value. The platform should also allow users to define their own servers as trusted so that these servers are preferred over others and their responses are assumed to be valid without needing redundant verification.
Simple Cryptography APIs
The platform should provide easy-to-use APIs to securely encrypt, decrypt, sign, verify, and hash messages and streams using the identities and key management solutions described above. The APIs should also support operations on keys including random key generation, deterministic key derivation, public key recovery from a signature, and ECDHE shared secret exchanges between key pairs.
Because even properly implemented cryptographic primitives are often used insecurely in practical scenarios, these APIs should be designed carefully to provide simple and properly implemented logical cryptographic operations rather than to provide the most mathematically pure reproduction of the underlying primitives.
Loading and Verification of Application Code
In order to secure the application code prior to execution, the blockchain must define a record of applications, queryable by name, which defines information such as what keys can update the application and where the application code can be found. Application code and resources can be bundled together and stored online, retrievable by their hash using IPFS.
The platform should provide a way for users to enter a desired application’s name (similar to an address bar in a web browser), and it should look up the application in the blockchain database, fetch the code bundle, and validate it prior to execution.
Establishment and Authentication of Network Connections
Application runtime operations should be secured as well as the application code and resources. In particular, applications may wish to form network connections to other users or to various servers. These connections should be established securely with no reliance on trusted certificate authorities.
The blockchain can define a record of names to internet addresses and keys. The well-known Transport Layer Security (TLS) protocol can be utilized in its Pre-Shared Key (PSK) mode to form secure connections without reliance on certificate authorities. A simple
protocol can be defined to generate single-use PSKs using an Elliptic Curve Diffie-Hellman Exchange (ECDHE) to secure and authenticate the TLS channel without rendering nodes vulnerable to the TLS-PSK Selfie Attack.
The platform should provide simple "connect-to-name" APIs which look up the name on the blockchain to find a key and use this to establish secure connections over the network.
Services Network
The design goal of featuring dynamic infrastructure requires a network for the automated discovery of services, data, and peers. This automatic discovery of services, data, and peers will enable applications on the platform to self-configure even when nodes and data are dynamic and mobile. This network can be created using the libp2p protocol and can be integrated with the IPFS network for data discovery. To ensure that network traffic remains lightweight, it will route broadcast and discovery messages only; other message types must be carried on direct peer-to-peer connections.
The network will consist of blockchain nodes, application services (both commercial and gratis), and user devices, and will facilitate the automatic discovery of services and formation of connections to services or other nodes, even when nodes are firewalled and unable to receive connections directly.
The platform should provide reference implementations of nodes and services to demonstrate how the network operates and how to connect to it and send messages and receive connections.
User-to-User Networking
In the modern internet, nearly all user devices are behind firewalls which prevent direct communication between user devices and keep user devices from listening online for connections from other systems. This precludes the possibility of entire classes of dApps using peer-to-peer technology; for example, video conferencing applications require all streams to be processed by a central server which is wasteful of network resources compared to direct user-to-user streaming, and may not be suitable for private conversations. If user-to-user connections could be established, it would enable a new generation of efficient and low-cost serverless P2P applications.
Although direct user-to-user connections are not possible with existing internet technology, the effect can be simulated via the use of proxy servers which listen for incoming connections on behalf of a user device and forward messages back and forth between users. The servers can be automatically discoverable on the services network, and the channels can be end-to-end encrypted and authenticated so that the proxy server cannot read or tamper with the forwarded messages.
The platform should provide reference implementations for such proxy servers and demonstrate their usage in gratis, membership based, and commercial scenarios. Free-to-use, low-volume proxy services should be provided by most nodes in the network so that user devices can automatically negotiate a public address to receive responses to service discovery broadcasts they send over the network.
Off-Chain Data Storage
A primary concern of many blockchains today is the forever increasing data weight of the blockchain history. This problem is exacerbated by the fact that blockchain-based applications have few options for secure data storage except to encode their data directly into the blockchain. To mitigate this issue, solutions for secure, off-chain data storage must be found.
Typical blockchain applications today publish application data to the chain. An alternative approach would be to host the data on IPFS and post only the IPFS Content ID (hash) of the data on the chain. This will significantly reduce the data weight on-chain.
Initially, the data can be hosted, via a proxy server as described above, by the user device that posted it. IPFS will allow nodes in the network which see the transaction on-chain, and wish to fetch the data, to locate the user and download it as long as the user remains online. If the dApp developer wishes to improve the availability of his application’s data, he can contract one or more commercial hosting providers to monitor the chain and download data postings from users immediately while the user is still online, then continue hosting it after the original poster disconnects from the network. Users can also host any records they choose directly, making it virtually impossible to centrally censor data that users find valuable.
The platform should provide reference implementations and examples of this model in action.
Discussion and Summary
This PIP describes Follow My Vote's proposal of a decentralized application (dApp) platform which will be developed to deploy applications based upon Peerplays and other blockchains to user devices. This platform will include supporting technologies, and guidelines and examples showing how to utilize the technologies effectively to quickly and easily develop blockchain applications which are understandable to non-technical users and secured to a degree unprecedented in the blockchain space. Follow My Vote anticipates that this platform will catalyze the blockchain industry enabling it to solve complex societal problems at scale.
Follow My Vote believes Peerplays is an ideal blockchain to pilot the dApp platform, and if the community is supportive of the idea, Follow My Vote would like to develop the platform with Peerplays as the first public blockchain back-end. This will give Peerplays an advantage over other blockchains until those chains integrate with the platform as well.
The dApp platform does not necessarily require changes to Peerplays core consensus logic, and can be implemented without requiring any hard-forking changes; however, there will be some consensus changes which can make the platform integration easier and stronger. These will be proposed at a future date.
Follow My Vote is currently in the planning phase of the dApp platform project, and is actively developing the technologies and guidelines that will inform the architecture of the platform. They anticipate that the platform can be made into reality within 12-18 months.
Follow My Vote hopes that this idea will be exciting to the Peerplays community and eagerly awaits the community's response to their plans to build the platform here.
Thank you!
Copyright
This document is intended for the betterment of humanity, and is hereby placed into the public domain.
Abstract
This PIP describes Follow My Vote's proposal of a decentralized application application platform which provides supporting technology and guidelines for the development and deployment of blockchain-based applications. This platform is intended to make decentralized applications easier for non-technical users to understand, to secure these applications to the same standards as the blockchain itself, and to reduce costs and accelerate the development of these applications.
The platform will be built of a dApp browser that runs on user devices, and a services network. The platform will be designed to be able to integrate with many blockchains, but is expected to launch on Peerplays initially.
Context and Motivation
Since their inception, blockchains have shown promise as potential solution strategies for a vast range of complex societal problems, as well as opening the door to powerful new financial and contract applications which were infeasible with previous technology due to questions of honesty or fairness; however, the industry has had difficulty delivering on these promises without making compromises which are unacceptable for high sensitivity application domains such as those involving reputation or finance. This has led Follow My Vote to examine the situation in an attempt to understand why, although blockchain is so promising, uncompromising solutions have not so far been forthcoming.
The creation of user-friendly, effective blockchain applications is difficult for two main reasons. First, blockchain databases are controlled by complex and rigid protocols controlling the state of the system and updates to this state; however, these databases are useful only inasmuch as they can be used by laypeople who do not understand the protocols and do not naturally think in the same way as the protocols operate. Second, these databases are stored and tracked by servers, but the people whom they are intended to benefit are distant from those servers, interacting from either desktop computers or mobile devices.
In order to make these systems helpful to people, it is necessary to create an adaptive layer of software which deals with the relevant topics in a manner cognizable to humans and translating this human interaction into the formal protocols which control the data. This adaptive layer, known as the application software, necessarily runs on user devices rather than on the secured server systems, and constitutes the user’s only point of contact with those back-end systems and the data they track.
The application layer is the source of most of the difficulty in creating viable solutions to the problems blockchains should excel at. Although creating smart contract back-ends on the servers requires advanced skills, the industry has been largely successful in creating these solutions. On the other hand, the human-facing applications for these contracts, although being simpler technologically and requiring less advanced skills to craft, consume far greater resources and timelines to create, while the end result frequently leaves non-technical users confused or frustrated.
Compounding this issue, blockchain applications are largely built upon technologies originating in the pre-blockchain era that are not secured to the advanced standards of the blockchain protocols themselves. While this may be suitably adequate for CryptoKitties, applications with real world implications must be secured against all threats, and relying on architecturally insecure, legacy technology is unacceptable in these domains. To illustrate this point, consider an application based upon these lower standards. This application could be compromised in order to manipulate the information displayed to, or received from, the user, to act falsely on the user's behalf, or possibly even to detach the application from the legitimate blockchain back-end altogether. The user would be unable to detect this tampering without utilizing advanced technical skills.
In order to provide solutions to the sensitive problems that blockchain can address, applications must be developed to be naturally understandable to the humans using them, and must be deployed and operated upon technological underpinnings which are as secure as the decentralized back-ends themselves.
At present, however, no platform exists to provide for the full scope of the development, deployment to user devices, and executional operations of decentralized applications. Blockchains themselves are merely smart contract platforms; they are not decentralized application platforms, and the technologies typically used to support blockchain-based application deployment are based on the world-wide web and do not embody security standards on par with the blockchain.
A new kind of solution is required; not a new blockchain, but rather a decentralized application platform that operates on the user's device, designed to protect the user's keys, reputation, and privacy, by loading and verifying decentralized application code using only protocols secured to the same standards as the blockchain back-ends themselves, and then providing those applications with a secure environment featuring powerful tools to enable the application to easily utilize advanced technologies to empower the user to act and interact online safely and with confidence that not only is their technology rigorously secure and working for no-one but them, but also that they fully understand its capabilities and the effects their actions will have.
Rationale
The decentralized application (dApp) platform is intended not only to secure dApp deployment and operations, but to facilitate the creation of user-friendlier dApps with shorter timelines and smaller budgets and better developer experiences than even the web can offer. To accomplish this inimitable goal, the platform will be not only a set of supporting technologies, but also a system of guidelines, documentation, and examples to ensure that the technologies are easy to use properly and difficult to use improperly.
Follow My Vote has selected several design goals to inform the design of the platform. First, the platform and documentation must be designed to ensure that developers can easily create applications which non-technical users will understand naturally.
Second, the platform must feature rigorous security standards, ensuring that application code is cryptographically authenticated before it is executed, and implementing developer-friendly APIs for the application to perform standard operations, such as network connections, with full authentication and encryption. All security protocols must function without reliance on centrally trusted providers; in instances where a degree of trust is necessary, the protocols must distribute this trust among several providers such that all providers should agree and therefore erroneous responses can be detected.
Third, the platform should emphasize dynamic rather than static infrastructure. Much of distributed software today utilizes what may be referred to as "static" infrastructure, where remote data and servers are located by URLs, IP addresses, and domains which indicate where the desired resource can be found. In these systems, whatever resource is found in the specified location is typically assumed to be valid without further verification. The platform should provide easy models for dynamic infrastructure, where desired resources are specified not by location, but by content: data is referenced by hash, and servers are referenced by public key. Thus, embedded within the app is the necessary information to recognize the correct resource when it is located, and the platform provides protocols to dynamically locate and verify the desired resource on-demand.
Finally, the platform must provide APIs that are easy for developers to understand and use correctly, along with documentation and examples covering their proper usage, so that applications can be developed easily with minimal time to market.
Specification
Current blockchain applications are developed and deployed using legacy web technologies with inadequate library support for the concerns universal to smart contract user interfaces. This results in the technical realities of the underlying blockchain protocols showing through the app to the user, causing confusion and frustration for non-technical users who are not familiar with the protocols governing blockchain systems.
To alleviate these problems, a dApp platform is proposed which facilitates the development of decentralized applications, and the secure deployment of these applications on user devices. At a technological level, the platform will be comprised of a dApp browser and a services network.
The dApp browser will run on the user device and provide a similar function to a web browser, but will use only technologies and protocols which secure the applications on the user device to the same level as the blockchain databases which underlie them. The browser will implement APIs to provide critical functionality to apps so that easy-to-use apps can be developed quickly and easily.
Platform Functionality
The platform will provide functionalities to accelerate application development while making it easy to create applications that make sense to users not already familiar with blockchain protocols. These usability functionalities include identity and key management, database caching, transaction management and modeling, and non-technical documentation of user interface controls and symbols. Issues surrounding these topics are common to most or all dApps, and to address them properly, technological solutions must be innovated.
Other functionalities are necessary to secure the deployment and operations of decentralized applications on user devices. These functionalities include secure queries of blockchain APIs, simple APIs for essential cryptographic operations, application code retrieval and verification, and network connection establishment and authentication.
Finally, some technologies are included to push the blockchain industry forward in places it is currently struggling. These include protocols for off-chain data storage, and infrastructure supporting user-to-user network connections.
Each of these critical functionalities will now be examined in greater detail.
Identity and Key Management
One of the most fundamental concerns in any multi-user software system is authentication. Historically, systems have addressed this concern via username and password pairs, and although few users tend to favor the password concept and the paradigm yields a generally weak security model, the password is familiar to most users, and thus the solution works, even if few people still believe it is a good one.
Blockchains, however, do not use passwords as an authentication mechanism, instead relying on cryptographic key pairs. This technology is unfamiliar to non-technical users, and thus simple user interfaces must be created to enable such users to interact with the blockchain. These interfaces should be provided without disenfranchising advanced users, however, who are familiarized with key management and wish to secure their keys according to their own standards.
Therefore, the platform should provide a simple and effective key management system which non-technical users can easily utilize, but simultaneously it should seamlessly integrate with popular external wallet applications where possible, and it should also be possible to utilize custom or unrecognized key handling solutions if an advanced user wishes to do so. All of these key management strategies should be exposed to applications via a consistent, well-documented, and easily used API.
Database Caching
In order for applications to operate in any networked software system, the user application must have access to shared data and must be able to store some of that data in a local cache for display and modification. While myriad solutions for this may exist in standard client-server environments, these solutions typically require greater support from the server than is typically available in blockchain systems. In these systems, applications are required to operate with basic data query and subscription APIs, or else rely on off-chain data storage servers which degrade the trust model and increase the system’s attack surface.
The platform should provide chain-specific solutions for sparse data caching and offer reasonable strategies for tracking and maintaining the freshness of the cached data.
Transaction Management and Modeling
All updates to shared data in blockchain databases are processed via irreversible transactions. This model of access control is alien to incoming users, as most client-server software systems allow users direct and arbitrary modification of data on demand.
As a result, blockchain applications must cache local changes to the data in order to show the user an updated view of the system. When the user wishes to commit their changes, the application must sign and broadcast the transaction and track its status until it is confirmed.
To ensure that the front-end and back-end can be developed and upgraded in synchronization, blockchain applications should internally model their local changes as draft transactions which are applied to the local database cache. The application should also monitor the back-end for unexpected or conflicting changes and notify the user if their desired actions are no longer possible.
The platform should provide mechanisms for applications to define their custom transaction types and implied modifications to the database cache, as well as track the status of local edits to cached data, so that applications can always show users a system state that is up-to-date and includes the user’s draft changes.
Interface Documentation
Even well-designed user interfaces are often confusing to new users, and in many cases, interface controls and symbols are ambiguous as to their exact purpose. Applications controlling highly sensitive data should go the extra mile to ensure that users can understand and predict what effect their actions will have before making irreversible changes.
While the transaction model of changes does help with this effect, there is still room for improvement by adding clear, non-technical documentation of the symbols and controls of the user interface.
The platform should offer a standard for applications to define documentation text describing clearly and unambiguously what UI controls do and what symbols mean. The platform should allow users to "inspect" a UI to access this information. Guidelines on how to write this documentation well should be provided so that developers can create high quality documentation which yields a tangible benefit to users.
Secure Blockchain API Queries
Whereas in traditional client-server computing, a trusted server provides the single source of information about the status of shared data, in blockchain systems there are typically many nodes available hosting the system state for query, and all of these nodes should give identical responses to any given query.
The platform should provide a simple API for querying these servers and should allow tunable security requirements to define the number of agreeing responses which are required to validate a value. The platform should also allow users to define their own servers as trusted so that these servers are preferred over others and their responses are assumed to be valid without needing redundant verification.
Simple Cryptography APIs
The platform should provide easy-to-use APIs to securely encrypt, decrypt, sign, verify, and hash messages and streams using the identities and key management solutions described above. The APIs should also support operations on keys including random key generation, deterministic key derivation, public key recovery from a signature, and ECDHE shared secret exchanges between key pairs.
Because even properly implemented cryptographic primitives are often used insecurely in practical scenarios, these APIs should be designed carefully to provide simple and properly implemented logical cryptographic operations rather than to provide the most mathematically pure reproduction of the underlying primitives.
Loading and Verification of Application Code
In order to secure the application code prior to execution, the blockchain must define a record of applications, queryable by name, which defines information such as what keys can update the application and where the application code can be found. Application code and resources can be bundled together and stored online, retrievable by their hash using IPFS.
The platform should provide a way for users to enter a desired application’s name (similar to an address bar in a web browser), and it should look up the application in the blockchain database, fetch the code bundle, and validate it prior to execution.
Establishment and Authentication of Network Connections
Application runtime operations should be secured as well as the application code and resources. In particular, applications may wish to form network connections to other users or to various servers. These connections should be established securely with no reliance on trusted certificate authorities.
The blockchain can define a record of names to internet addresses and keys. The well-known Transport Layer Security (TLS) protocol can be utilized in its Pre-Shared Key (PSK) mode to form secure connections without reliance on certificate authorities. A simple protocol can be defined to generate single-use PSKs using an Elliptic Curve Diffie-Hellman Exchange (ECDHE) to secure and authenticate the TLS channel without rendering nodes vulnerable to the TLS-PSK Selfie Attack.
The platform should provide simple "connect-to-name" APIs which look up the name on the blockchain to find a key and use this to establish secure connections over the network.
Services Network
The design goal of featuring dynamic infrastructure requires a network for the automated discovery of services, data, and peers. This automatic discovery of services, data, and peers will enable applications on the platform to self-configure even when nodes and data are dynamic and mobile. This network can be created using the libp2p protocol and can be integrated with the IPFS network for data discovery. To ensure that network traffic remains lightweight, it will route broadcast and discovery messages only; other message types must be carried on direct peer-to-peer connections.
The network will consist of blockchain nodes, application services (both commercial and gratis), and user devices, and will facilitate the automatic discovery of services and formation of connections to services or other nodes, even when nodes are firewalled and unable to receive connections directly.
The platform should provide reference implementations of nodes and services to demonstrate how the network operates and how to connect to it and send messages and receive connections.
User-to-User Networking
In the modern internet, nearly all user devices are behind firewalls which prevent direct communication between user devices and keep user devices from listening online for connections from other systems. This precludes the possibility of entire classes of dApps using peer-to-peer technology; for example, video conferencing applications require all streams to be processed by a central server which is wasteful of network resources compared to direct user-to-user streaming, and may not be suitable for private conversations. If user-to-user connections could be established, it would enable a new generation of efficient and low-cost serverless P2P applications.
Although direct user-to-user connections are not possible with existing internet technology, the effect can be simulated via the use of proxy servers which listen for incoming connections on behalf of a user device and forward messages back and forth between users. The servers can be automatically discoverable on the services network, and the channels can be end-to-end encrypted and authenticated so that the proxy server cannot read or tamper with the forwarded messages.
The platform should provide reference implementations for such proxy servers and demonstrate their usage in gratis, membership based, and commercial scenarios. Free-to-use, low-volume proxy services should be provided by most nodes in the network so that user devices can automatically negotiate a public address to receive responses to service discovery broadcasts they send over the network.
Off-Chain Data Storage
A primary concern of many blockchains today is the forever increasing data weight of the blockchain history. This problem is exacerbated by the fact that blockchain-based applications have few options for secure data storage except to encode their data directly into the blockchain. To mitigate this issue, solutions for secure, off-chain data storage must be found.
Typical blockchain applications today publish application data to the chain. An alternative approach would be to host the data on IPFS and post only the IPFS Content ID (hash) of the data on the chain. This will significantly reduce the data weight on-chain.
Initially, the data can be hosted, via a proxy server as described above, by the user device that posted it. IPFS will allow nodes in the network which see the transaction on-chain, and wish to fetch the data, to locate the user and download it as long as the user remains online. If the dApp developer wishes to improve the availability of his application’s data, he can contract one or more commercial hosting providers to monitor the chain and download data postings from users immediately while the user is still online, then continue hosting it after the original poster disconnects from the network. Users can also host any records they choose directly, making it virtually impossible to centrally censor data that users find valuable.
The platform should provide reference implementations and examples of this model in action.
Discussion and Summary
This PIP describes Follow My Vote's proposal of a decentralized application (dApp) platform which will be developed to deploy applications based upon Peerplays and other blockchains to user devices. This platform will include supporting technologies, and guidelines and examples showing how to utilize the technologies effectively to quickly and easily develop blockchain applications which are understandable to non-technical users and secured to a degree unprecedented in the blockchain space. Follow My Vote anticipates that this platform will catalyze the blockchain industry enabling it to solve complex societal problems at scale.
Follow My Vote believes Peerplays is an ideal blockchain to pilot the dApp platform, and if the community is supportive of the idea, Follow My Vote would like to develop the platform with Peerplays as the first public blockchain back-end. This will give Peerplays an advantage over other blockchains until those chains integrate with the platform as well.
The dApp platform does not necessarily require changes to Peerplays core consensus logic, and can be implemented without requiring any hard-forking changes; however, there will be some consensus changes which can make the platform integration easier and stronger. These will be proposed at a future date.
Follow My Vote is currently in the planning phase of the dApp platform project, and is actively developing the technologies and guidelines that will inform the architecture of the platform. They anticipate that the platform can be made into reality within 12-18 months.
Follow My Vote hopes that this idea will be exciting to the Peerplays community and eagerly awaits the community's response to their plans to build the platform here.
Thank you!
Copyright
This document is intended for the betterment of humanity, and is hereby placed into the public domain.