Unlike most blockchain projects that pay more attention to tokenism, PPIO places greater emphasis on the development of products for real application scenarios. I believe storage and data delivery is one of the most suitable business scenarios for blockchain technology because both storage and delivery can offer reduced prices through a bitcoin-like incentive.
PPIO’s Technology Architecture for Commercialization
To realize the overall PPIO architecture, we implemented a layered design which includes a blockchain layer, an incentive layer, a storage layer, a data delivery layer, and an application layer.
For a better perspective, we may compare PPIO’s technical architecture to that of traditional cloud services. You can think of PPIO as a decentralized AWS that provides different levels of services. Each level has its API output. Developers can use different APIs for their own applications. For example, you can choose to use the IaaS layer API if you only want to purchase storage and bandwidth from PPIO’s blockchain network. If you like to use an AWS-like object storage service, you can choose PaaS APIs such as POSS. An API on the Application Services layer is available for those who want to provide live streaming and video-on-demand streaming audio and video transmission services.
The fundamental difference between PPIO and centralized services is pricing control.
Centralized service providers have control over the price of their services. Because the service provider themselves deploys all nodes (data center and servers), there is no credibility problem. Without external resources being involved, there is no room for unfairness issues or evil nodes and online coupon clippers. As centralized service providers can control the cost, it is enough for them to implement a simple centralized pricing mechanism.
Decentralized service providers, on the other hand, value participation and competition. Participation allows external resources to enter the market freely. Because the market is open to the public, it’s highly possible that impartiality of distribution, evil nodes, or coupon clippers will emerge. Blockchain technology is the best solution so far to solve the above problems. Competition, in the PPIO network, refers to the regional level of resources competing. For the storage nodes, whoever offers the highest quality resources for the lowest price will win.
Below is the server room deployment diagram of Amazon Centralized Services (AWS)
The foundations of centralized services (such as AWS) and decentralized services (such as PPIO) are different.
Centralized services use expensive and centralized backbone network resources; building their own server rooms, buying machines, and build broadband fiber by themselves. These high infrastructure costs mean that centralized services providers do not build too many nodes.
Below is the node distribution map of future decentralized services such as PPIO.
Decentralized services use the blockchain to incentivize storage nodes and to encourage millions of miners to offer up their unused storage space to the network. The “server room” of a decentralized service is made up of inexpensive and decentralized resources. The result is that the number of nodes in a decentralized service is much more than in its centralized counterpart. What decentralized services need to do is to build stable services under relatively unstable infrastructure.
The centralized service is like a cloud. For everyone, a cloud is something far away from the ground. The decentralized service is like fog. The fog is everywhere around us and easy to access. I think fog computing, or edge technology, is appropriate to describe decentralized services.
The fundamental differences in the underlying infrastructure result in a considerable difference in the superstructure.
Generally speaking, there are three different types of to-business services.
IaaS: Infrastructure-as-a-Service
PaaS: Platform-as-a-Service
Application Services: Application Services
IaaS — Infrastructure as a Service
For AWS and other centralized services, the IaaS layer is used for hardware rental. For example, if you purchase a virtual machine on AWS’s EC2, you also need to buy basic hard disk and bandwidth. Each virtual machine is only equipped with limited hard disk space and bandwidth. If you want to increase the hard disk space or bandwidth, you need to pay extra. In essence, you get a naked server from AWS EC2, and you can decide what you want to do with it.
For a decentralized service provider like PPIO, the IaaS layer acts as a resource renter. Specifically, it provides hard disk and bandwidth rental; there is no packaging or other additional services. PPIO’s IaaS layer design can be divided into two parts. The first is pricing and incentives; the second is design logic.
Storage Design Logic
A user can choose nodes that they like to take up resources (storage and bandwidth) for a certain period that they pay for. They will then be charged by the actual use of these resources. Specifically, storage usage will be charged by the size of the Chunk and the take-up time; the traffic charges bandwidth resources.
Data Delivery Design Logic
Developers pay to deliver their data. Miners get paid by delivering data to those who request to download them. Therefore, the miner nodes will actively predict which files will be downloaded. If the miners can host the most popular and in-demand content as much as possible, they can get the most benefit.
If developers purchase the hard disk and bandwidth on the API of the IaaS layer, they are buying a minimum service. On the IaaS layer, PPIO does not support the erasure algorithm; the erasure algorithm is supported on the PaaS layer. In this regard, the decentralized service provides less stability of a single fragmented resource than that of the centralized service. Although PPIO supports the IaaS layer interface, it is not recommended for developers to directly use the IaaS layer interface.
PaaS Layer — Platform-as-a-Service
To get a better understanding of the PaaS layer, we need to have a look at how it works for centralized cloud services. PaaS is a universal service that has been packaged based on IaaS.
For AWS and other centralized services, the two most used PaaS services are OSS (Object Storage Service) and CDN (Content Delivery Network). AWS’s S3 service is an OSS service, which is for storage. AWS’s CloudFront is a CDN service, which is for data delivery. For a centralized service, OSS and CDN services are not built by a single machine; instead, multiple machines are required to be coordinated.
PPIO’s decentralized service also has two PaaS services: POSS and PCDN (with reference to OSS and CDN). These two services are not implemented by cloud servers but by multiple nodes.
POSS to Storage
Like AWS S3, PPIO implements the erasure algorithm in the Application Services layer. We use the erasure algorithm. Using this algorithm means that the file is divided into k shares and then expanded into n copies of the erasure code. The entire file can be recovered as long as any of the k shares in n copies stay online. Because of the erasure code, you can use a very small number of copies to greatly reduce the file loss rate.
Want to understand how our erasure algorithm works so your data is never lost? Read How PPIO Protects Your Data for more details.
PCDN to Data Delivery
The download engine of P2SP is on the PaaS Layer. P2SP is different from P2P. P2P offers peer-to-peer transmission between complete nodes. P2SP is Peer to Server and to Peer (here server refers to an HTTP/HTTPS server). P2SP allows you to download data from an HTTP server or other peers. Our method with PPIO does not wholly replace traditional CDN; instead, it supplements CDN with P2P technology. This method will reduce the cost and enhance the user experience.
The positioning of the PaaS layer is still universal and basic. What makes PPIO’s PaaS different from the IaaS layer is that the PaaS layer allows for a stable, reliable, and inexpensive service to be built on a relatively unstable infrastructure. However, PaaS is built to support relatively universal services, so there is no relationship with any special application scenarios on the PaaS layer.
PRoute (Intelligent Routing)
PRoute is designed by PPIO to find the nearest network path between two points. This can also be understood as intelligent routing. Intelligent routing is a conventional technology of P2P. So-called intelligent routing is designed to find the fastest stable transmission path between two nodes. It is implemented on the TCP/IP layer, not at the bottom of the network. PPIO’s intelligent routing supports multiple links.
Like traditional cloud services, audio, video, and media streaming are not implemented on the PaaS layer. When designing PPIO, we put audio and video streaming on the upper Application Services layer.
Application Services
Developers can design specific applications on the applications layer. PaaS provides common storage and data transfer scenarios. On the other hand, Application Services are geared towards scenes that are closer to vertical applications. As mentioned above, the majority of existing data distribution services are audio and video services. We have given significant consideration in supporting audio, video, and media streaming when designing PPIO.
For centralized cloud services, the services of the Application Services layer are very rich, and there are many applications, such as image applications, that can be designed. If developers upload an original image to the OSS, they can directly obtain images of different resolutions. Furthermore, Anti-theft, watermarking, and other functions can also be applied. Another example is a video service that supports various types of transport protocols and methods, such as HL-supported HLS (HTTP Live Streaming) and other unique transport methods. The application layer provides services to support application design. We abstract every possible application scenario and provide corresponding services. Developers can build an App or DApp through APIs on the application layer.
With the design of PPIO, we considered the solution provided by centralized services, then decided to allow for decentralized services to be built on the application layer to support application builders. On the PaaS layer, I also applied APIs close to the application scenario to facilitate speedier development for developers. Because PPIO’s implementation principle is different from traditional cloud services, PPIO nodes are everywhere around the user. I like to call it a fog service.
We plan to provide the Application Services layer interface in the near future, including live fog, video-on-demand fog, picture fog, audio communication fog, etc. Live fog and video-on-demand fog are our first priority for they comprise a large part of data applications.
The Application Services and PaaS layers are different. The PaaS layer gives a universal PCDN transmission method. It does not involve streaming media and slicing details. The Application Services layer is different. Quality (QoS) is the premise of video-on-demand applications and live streaming applications. The most basic QoS for videos is for them to start quickly, have zero stops during playback, and low latency.
In order to maximize the QoS performance, we must carefully analyze media streaming and conduct a detailed data slice and segment. When designing data transmissions, we use the urgency of data slicing as the basis for switching different download strategies.
For example, a slice of a universal file looks like this:
For FLV video, a slice looks like this:
Real-time Data Streaming
Besides supporting efficient file downloads, PPIO also supports optimized P2P data streaming. PPIO’s data-driven scheduler is designed to provide stable real-time streaming performance in an ad-hoc P2P network. The technology has gone through many iterations of trial-and-error optimizations and has been proven to provide a high-quality user experience to streaming applications such as video-on-demand (VOD) services.
A P2P streaming system has the following unique design characteristics:
Sequential downloads: Subsequent segments and pieces from the current point of playback need to be prioritized in download scheduling to maintain smooth streaming playback.
Unpopular pieces: Unpopular pieces are the ones with the smallest number of duplicates in the network. In a media streaming use case, they need to be prioritized during download. This may seem counterintuitive, but prioritizing these pieces will help make downloading of the entire segment much faster and achieve a better experience.
Anchor points: Many media streaming applications allow random access playbacks such as fast forwarding or seeking. Anchor points are placed in the video stream to enable random access. The pieces at the anchor point are prioritized during download to allow the playback to start immediately after random access.
PPIO’s P2P transmission network is fully dynamic. Each peer responds to multiple download requests, and potentially to numerous downloading nodes. Each downloading node sends download requests to multiple peers, manages downloaded pieces, and deals with potential timeouts and failures from the peers. At the same time, the downloading node itself can be serving download requests, working as a peer to other nodes. By utilizing the two data-driven scheduling algorithms, PPIO’s dynamic P2P network can efficiently handle an extremely high volume of simultaneous data transmissions.
In addition to the sharding and downloading algorithms, the Application Services layer will provide more specific services in terms of actual usage scenarios.
App Layer
The App layer is the application layer. This layer belongs to developers. Developers can develop a solution that fits their application based on PPIO’s three-tier API.
Below is the full picture of PPIO’s architecture.
To summarize, PPIO will provide three sets of APIs:
IaaS layer based storage space and bandwidth lease API
PaaS-based POSS, PCDN, and PRoute API
Application Services layer-based application APIs that support video-on-demand fog, live streaming fog, image fog, and more.
Developers can choose to develop at any level and complete their own App or DApp.
PPIO will incorporate as many idle resources as possible to ultimately achieve a cheaper, faster, and more private storage and data delivery service than current cloud services.
Want more? Join the PPIO Community on Discord or follow us on Twitter .