WO2020022957A1 - Procédé et appareil de vérification de transactions dans un réseau de chaînes de blocs - Google Patents

Procédé et appareil de vérification de transactions dans un réseau de chaînes de blocs Download PDF

Info

Publication number
WO2020022957A1
WO2020022957A1 PCT/SG2018/050380 SG2018050380W WO2020022957A1 WO 2020022957 A1 WO2020022957 A1 WO 2020022957A1 SG 2018050380 W SG2018050380 W SG 2018050380W WO 2020022957 A1 WO2020022957 A1 WO 2020022957A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
shard
verification
transactions
nodes
Prior art date
Application number
PCT/SG2018/050380
Other languages
English (en)
Inventor
Sang Nguyen
Quang Tran
Erman TJIPUTRA
Original Assignee
Aioz Pte Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Aioz Pte Ltd filed Critical Aioz Pte Ltd
Priority to PCT/SG2018/050380 priority Critical patent/WO2020022957A1/fr
Publication of WO2020022957A1 publication Critical patent/WO2020022957A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • the present invention re!ates to a method and apparatus for transaction verification in a blockchain-based network.
  • a sharding technique that may contribute to decreased network latency is uti!ised for the transaction verification.
  • the second biggest Blockchain-based network in terms of the total market cap i.e. the Ethereum network also faces the same scaling challenge as the Bitcoin network does. It had been reported that the Ethereum network produces an estimated speed limit of around 20 transactions per second. This number is much lower than the network’s current demand and causes user experience issues such as long confirmation time.
  • the first approach to mention is the use of an off-chain network in conjunction with a main-chain network.
  • off-chain networks By means of off-chain networks, transactions are executed off main-chains and are only updated back to the main-chains sparingly.
  • Such off-chain mechanism reduces significantly the workload on main-chains, thereby, generally improving the scalability of the entire network. Examples of such off-chain mechanism approach would be Raiden network and Lighting Network.
  • the Ethereum’s Sharding enables a transaction to be verified by a small subset of nodes instead of by all nodes of a Blockchain-based network. On top of that, as long as there are sufficiently many nodes verifying each transaction, the system would be still highly secure and the network’s throughput would likely increase significantly.
  • one of the major drawbacks of the Ethereum’s fixed sharding schema is that it requires the presence of receipts for transactions that happen across shards, which contributes to undesirable network latency.
  • the Ethereum’s system is such that, in order to send tokens from an address that belongs to one shard to an address of another shard, a receipt must be created to transfer tokens.
  • Figure 1 illustrates a prior art centralized video streaming infrastructure.
  • Figure 2 illustrates a proposed blockchain-based network according to an example of the present disclosure.
  • Figure 3 illustrates a payment model of the proposed network of Figure 2.
  • Figure 4 illustrates Byzantine Fault Tolerance Protocol.
  • Figure 5 illustrates a proposed version of a Delegated Byzantine Fault Tolerance Protocol that is according to an example of the present disclosure.
  • Figure 6 illustrates a proposed sharding technique according to an example of the present disclosure.
  • Figure 7 further illustrates the proposed sharding technique.
  • Figure 8 illustrates an example of method and apparatus for managing the proposed blockchain- based network.
  • Figure 9 is a schematic diagram showing components of a processor according to an example of the present disclosure.
  • An example of the present disclosure relates to a proposed blockchain-based (BCB) protocol to build decentralized video streaming infrastructures whereby users are incentivized to share redundant memory, storage and bandwidth resources to address today’s video streaming challenges.
  • the proposed blockchain-based (BCB) protocol is to be applied to a proposed network (also known herein as“a proposed blockchain-based network”), which will be referred to in many examples in the present disclosure.
  • a proposed network also known herein as“a proposed blockchain-based network”
  • Two ideas are proposed for the proposed network, namely, a consensus model called Delegated Byzantine Fault Tolerance that uses a unique Sharding technique, and three light weight proofs for video streaming processing tasks and services, including an Artificial Intelligence powered Proof of Transcoding procedure.
  • Section I explains motivation for building a decentralized solution for video streaming services. Discussion of the challenges of the current centralized video streaming platforms and a summary of one proposed solution can be found in this section. Section II presents the main functionalities and the current limitations of core components of a typical modern centralized video streaming infrastructure. Section III describes details of a proposed blockchain-based network designed specifically for decentralized video streaming services according to one example of the present disclosure. The network’s general architecture, its main stakeholders and their roles, details of consensus and validation model, and protocol specifications are included in this section.
  • the proposed network is blockchain-based, it has some generic features of a blockchain network.
  • a blockchain which is a continuously growing list of records, called blocks.
  • the blocks are linked and secured using cryptography.
  • Each block typically contains a cryptographic hash of the previous block, for instance, a timestamp, and transaction data.
  • a blockchain is resistant to modification of the transaction data.
  • It is an open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way.
  • a blockchain is typically managed by a peer-to-peer network collectively adhering to a consensus model that works based on a certain protocol (e.g. Delegated Proof-of-Stake, Proof-of-Work, or Proof- of-Stake) for inter-node communication and validating or verifying new blocks. Examples of the present disclosure would provide a method and an apparatus for transaction verification in the proposed blockchain-based network
  • a user device that can connect to the proposed blockchain-based network is referred to as a node.
  • the user device may be a desktop/laptop computer, a smartphone, a smart tablet device, video game console, smart television, television box (e.g. Android TV box) and the like.
  • a block of the proposed network may comprise the following main information:
  • issuer refers to one or more nodes that are involved with the one or more transaction
  • job identifier which refers to the job performed in the transaction
  • segment identifier which is applicable if the job performed in the transaction has to do with a segment of a file (e.g. a file segment is being transcoded by a node, stored by a node or delivered to a node);
  • digital signature or signatures of nodes involved with the one or more transaction digital signature or signatures corresponding to one or more witness (also known as verification node) verifying the one or more transaction; block hash;
  • transaction Merkle tree i.e. a Merkle tree of all transactions of the block; and nonce.
  • Block size number of transactions to record per block
  • File segment length in seconds that is applicable in the case that a transaction involves a segment of a file (e.g. a file segment is being transcoded by a node, stored by a node or delivered to a node);
  • banning bad actors in the network i.e. user accounts, nodes
  • An example of the voting process may be as follows. For example, anyone can propose a change to the proposed network through a node in the network. All core developers receiving the proposal on their respective nodes will review the proposals. If a proposal is technically reasonable and favorable, the core developers will officially trigger a voting round from a node. A voting round may last for a predetermined amount of time. During the voting time, any accounts (i.e. the nodes) of the proposed network can vote by staking tokens each of them possesses. Strength of a vote is determined by how many tokens a node stakes. After a voting round is completed, and a majority of the voting nodes that is determined based on voting strength of each vote agrees on a proposed change, the proposed change will take effect.
  • Live video streaming is the perfect way to connect with your audience, because people tend to engage on a deeper level via video, thanks to the visually stimulating and interactive nature of a live broadcast.
  • live streaming can be used to conduct interviews, share live events, and grant exclusive, behind-the-scenes access. The possibilities are nearly endless.
  • Video marketing is one viable choice now. Across all social media platforms, in a wide variety of industries, among a large and diverse audience, video and live streaming services are gaining popularity.
  • CDN Content Delivery Network
  • a typical lifecycle of a video within a CDN is as follows:
  • video contents After it is uploaded to a CDN, video contents will be transcoded into different codecs, formats, and resolutions.
  • CDNs store and distribute these transcoded videos to their distributed infrastructure for later consumption. Depending on the devices’ requirements, capacities and the users’ network bandwidth, CDNs will pick the suitable bitrate and codec video files to serve viewers.
  • CDNs usually cache frequently requested contents into in-memory storage that is RAM, in order to avoid long buffering times.
  • CPU Central Processing Unit
  • GPU Graphics Processing Unit
  • Participating devices can be data center servers, household desktop computers, personal laptops or even mobile phones.
  • the network of these kinds of devices by nature form a geographically distributed infrastructure that benefit the content delivering process.
  • Video contents can be easily distributed/served to/from different parts of the world.
  • a decentralized peer-to-peer network that can offer improved video delivery at lower costs.
  • DApps Decentralized App-enabled
  • Table II below provides a comparison between a centralized platform and a decentralized platform.
  • the decentralized platform is being proposed in the present disclosure.
  • decentralized network helps to
  • FIG. 1 A typical architecture 100 of a live streaming platform is shown in Figure 1 .
  • Such architectures include two main components which are a Transcoder 104 and a Content Delivery Network 106.
  • Transcoder 104
  • a Video Source 102 created by a content creator 108 is consumed on a wide variety of devices and each device has its own codec, color-space and resolution requirements.
  • Examples of the wide variety of devices include a smartphone 1 18 with, for example, viewing requirements of High Definition 720p and video formats of VP8/WebM, a desktop/laptop computer 120 with, for example, viewing requirements of High Definition 720p and video formats of VP8/WebM, a smart television 122 with, for example, viewing requirements of High Definition 720p and video formats of VP8/WebM, and the like.
  • the video source 102 is delivered to end-users i.e. viewers 1 16, it is transcoded by transcoders to match the device requirements.
  • Transcoding to be performed by a transcoder 104 is a combination of trans-coding, trans sizing, and trans-rating. Transcoding allows content providers to simultaneously stream the same video content at different frame and bit rate sizes, so that the end user can view the content in any format, at any quality level, without altering the integrity of the video itself.
  • a typical video services platform needs to support RTMP, FILS, Mpeg-Dash video formats in H.264 and VP8 codec. New codecs like H.265/HEVC, and VP9 will become more popular in the near future as consumers become more accustomed to higher video quality.
  • Transcoding in general, is an expensive conversion process as it comes at the cost of high CPU/GPU 1 10 requirements in return for high levels of compression. To cite an example, in an experiment that was conducted, even high-end cloud CPU instances 1 10 performed poorly, at 1 -2 FPS for transcoding a 4K x 4K video VR video.
  • CDN Content Delivery Network
  • CDNs 106 store and distribute these transcoded videos to their distributed infrastructure for later consumption.
  • CDNs 106 pick suitable bitrate and codec video files to serve viewers 1 16. Videos are usually delivered in chunks over the Internet using servers that are geographically in close proximity to consumers. CDNs 106 usually cache frequently requested contents into memory storage 1 12 that is, Random Access Memory (RAM), in order to avoid long buffering times.
  • RAM Random Access Memory
  • Figure 2 is a general architecture of a proposed decentralized video streaming network 200 according to an example of the present disclosure.
  • Figure 3 further explains a proposed payment model between several roles present in the proposed network 200. Each role is known as a node in the proposed network 200 and each node is a user device.
  • video is mentioned below and in many examples of the present disclosure, it is appreciated that the features applicable to video are also applicable to audio file or any type of file, including text file, presentation file (e.g. powerpoint file), pdf and many more. Storage, distribution and delivery of these non-video files are also supported by the proposed network 200. Audio files can be transcoded and a transaction involving audio file transcoding can be verified through the proposed network 200 as well.
  • audio file can be transcoded and a transaction involving audio file transcoding can be verified through the proposed network 200 as well.
  • the content creators 202 are the ones that wish to transcode, store and publish their video contents using the network’s 200 resources.
  • Content creators 202 can pay miners 204, 208, 210, and 212 who perform these tasks.
  • Content creators 202 get paid by viewers 214 who consume their premium video contents using end-user devices such as a smartphone 216 with, for example, viewing requirements of High Definition 720p and video formats of VP8/WebM, a desktop/laptop computer 218 with, for example, viewing requirements of High Definition 720p and video formats of VP8/WebM, a smart television 220 with, for example, viewing requirements of High Definition 720p and video formats of VP8/WebM, and the like.
  • the miners 204, 208, 210 and 212 can be any users that have unused resources and who wish to earn money from the unused resources by contributing their computing power, network bandwidth and storage to the network.
  • the miner 204 helps to transcode video content to be displayed on a desktop/laptop computer 218.
  • the miner 206 helps to store video content from a Content creator 202.
  • Miner 208 helps to transcode video content to be displayed on a smartphone 216.
  • the miner 212 helps to transcode video content to be displayed on a smart television 220.
  • the miner 210 helps to store transcoded video content for delivering to viewers 214.
  • the miners can work with other miners to store or deliver pre-transcoded and post-transcoded video content as illustrated in Figure 2.
  • the miners 204, 208, 210 and 212 can get paid by content creators 202, advertisers 302 and viewers 214.
  • content creators 202 may hire Miners 204, 208, and 212 to perform video transcoding, getting Miner 206 to store the content creators’ pre-transcoded video content and getting Miner 210 to store post-transcoded video content for delivery to viewers 214.
  • the advertisers 302 may hire any one of the Miners 204, 208, 210, and 212 to place the advertisers’ ads into video content that is served to viewers 214.
  • the viewers 214 may hire Miners 208, 210 and 212 to deliver video content to the viewers
  • the viewers 214 can also pay miners 208, 210 and 212 to enable ads-free watching mode, which has no ads in the video content served to the viewers 214.
  • the advertisers 302 may be the ones who pay for such run-time advertisements (ads) that are embedded into the video content.
  • the viewers 214 are the ones who request video streams from miners 210, 208 and 212, and pay these miners for the streams.
  • the viewers 214 may also pay the content creators 202 directly for providing premium content such as video content with higher video quality.
  • the viewers 214 may view the video streams or re-play them through a gateway to their applications (apps) operated, for instance, on the viewers’ smartphone 216, desktop/laptop computer 218, smart television 220 and the like.
  • Viewers 214 may get paid by the advertisers 302 for participating in a marketing campaign. For example, when video content being viewed by a viewer is attached with clickable ads, viewers 214 can get paid by performing social actions, for example, like, share, view and comment toward the ads.
  • the advertisers 302 may define and pay rewards for each action. Settlement and reward systems can be executed on the proposed Blockchain-based network 200 using smart contracts to ensure transparent and genuine results.
  • the advertisers 302 are the ones that wish to place their ads into the network’s 200 video content. To do so, the advertisers 302 may pay miners 204, 208, 210, 212, and 206, and content creators 202 for each and every ad they want to add to the miners’ video content.
  • the payment model can be a subscription model or a per click model.
  • the advertisers 302 can also attract user engagement by paying for social actions, for example, like, share, view and comment, that the viewers 214 perform towards their ads.
  • the advertisers 302 are able to define the reward value for each action.
  • each video is segmented into parts to be distributed in the network for storage unless a user of a node chooses not to segment.
  • Each part is not the full video but is a playable fraction or portion of the full video.
  • peer-to-peer connections are established between the nodes. The video segments will be transferred through these connections.
  • Geographical location information of nodes is one of the factors that will be considered for where a video segment is stored. How a video segment is stored geographically is decided by the content creators 202. For example, if a content creator C likes to upload his video to the proposed network 200. During the uploading process, the content creator C will be asked to provide his preferred regions to store the video segments of his video. For instance, he may want to have his video stored in three different geographical regions, which are Asia, Europe, and America. In this case, through a user interface provided to use the proposed network 200 at each node, a video storage job can be created by the content creator C with the three geographical regions specified by the content creator C. The job will be broadcasted to all the nodes of the proposed network 200 in the three specified regions.
  • miner nodes e.g. 206 of Figure 2
  • miner nodes are able to send their offers to the content creator 202 if they wish to perform the video storage job and get paid in tokens or crypto-currency coins by the content creator C.
  • the content creator 202 is able to pick the most suitable offers according to his needs.
  • the content creator 202 is free to decide which of the nodes will store his video.
  • automation tools may be provided to assist content creators 202 to choose the most optimal nodes to store their video. These tools can be an add-on to the proposed network 200. Such tools can be separate or be part of the protocol stack of the proposed network 200.
  • a video is delivered in segments over the Internet using nodes that are geographically in close proximity to the one or more viewers 214 of the video.
  • videos are each fully replicated to different data centers, which are located in a number of geographical regions.
  • a principal unit of video streaming may be a video segment and not a full video like the case of the centralized environment.
  • the content creator 202 of the proposed network 200 may still choose not to segment his/her video into parts but the option for video segmentation is available. If a video stream that had been segmented is requested by a viewer 214, the following would take place for the proposed network 200.
  • the user interface provided at each node in the proposed network 200 or at each node belonging to the viewer 214 comprises a video player.
  • the viewer 214 may request to view a specific video selected using the video player and upon selection, the video player is configured to query or request for:
  • geolocation information that may include IP address of the one or more node that is storing each video segment.
  • the video segments may be distributed and stored among nodes in the proposed network 200 according to which node or nodes the content creator 202 chooses. However, the content creator 202 can also apply default storage settings provided by the proposed network 200 and in this case, the proposed network 200 would propose to the content creator 202 how the video segments can be stored. If the content creator 202 accepts the proposal, the video segments would be stored as proposed.
  • the video player is configured to select one or more closest node out of all the available nodes storing each video segment so that one or more closest node can deliver the video segment to the video player for playing.
  • the proposed network 200 is configured to deliver the full video to the viewer 214 through video segments of the full video that are served from multiple nodes.
  • the proposed network 200 is configured such that if the default storage settings are applied, there would be a failover mechanism. This means that each segment of a video can be stored in a number of nodes. In the case that one of the nodes is not available to supply that video segment, the video segment can still be supplied by other up and running node or nodes.
  • the proposed network 200 may be configured to provide an adaptive streaming feature as well. This feature auto-adjusts display resolution of each video segment by considering Internet speed of each viewer 214. For example, if the viewer 214 has slow Internet speed, each video segment would be displayed at the node of the viewer 214 with lower display resolution so as to ensure smooth delivery of the video.
  • the mechanism to auto-adjust the display resolution (i.e. the adaptive streaming feature) and mechanisms to deliver video content (i.e. latency optimization technique and failover mechanism), which are provided by the proposed network, are different sets of mechanisms.
  • the proposed network 200 when a video is delivered to viewers 214, all the three mentioned mechanisms are employed to provide the best user experience. For example, when a video is uploaded to the proposed network 200, the video will be transcoded into various lower-resolution videos. One or more miners (e.g. 204, 208, 21 0 and 212) may be involved to perform such transcoding or the content creator 202 performs such transcoding at its node. Both the original video and the transcoded lower- resolution videos are then cut into, for example, 10-second segments.
  • miners e.g. 204, 208, 21 0 and 212
  • Each of the segments can be stored in a plurality of nodes in the proposed network 200 through the request of the content creator 202 and one or more miners (e.g. 204, 208, 210 and 212) may be involved to store the segments.
  • the adaptive streaming feature will recommend the most optimal display resolution, R1 , to play the video.
  • the transcoded video that is at the resolution, R1 will be retrieved at the node of the viewer 214 to serve to the viewer 214.
  • the proposed network 200 Given that the video was cut into 10-second segments, the proposed network 200 will deliver the video segment- by-segment to the viewer 214 from where the segments are stored.
  • each segment it is preferable that each segment is duplicated and stored on a plurality of nodes and if the content creator 202 does not opt out of it, a default setting of the proposed network would duplicate each segment and store them on the plurality of nodes. That is, a copy of each segment is stored in each node of the plurality of nodes.
  • a latency optimization technique is utilised by the proposed network to help identify a node that is geographically closest in terms of proximity to the viewer 214, and the closest node would then deliver the segment to the viewer 214.
  • the failover mechanism enables the video segment to be streamed from the next closest node.
  • the proposed network 200 of the above described example comprises a proposed consensus protocol using a unique Sharding technique, and three proposed light-weight proofs for video processing and services. These features would now be described.
  • the proposed blockchain-based network 200 employs a collection of algorithms and mechanisms, namely, Delegated Proof-of-Stake protocol, Byzantine Fault Tolerant, and a unique Sharding technique, to build the proposed consensus model or protocol.
  • a collection of algorithms and mechanisms is known herein as the proposed protocol Delegated Byzantine Fault Tolerance.
  • the Delegated Byzantine Fault Tolerance protocol helps to address performance and scalability issues associated with current blockchain implementations, thereby boosting a verification process for video streaming and video processing transactions.
  • verification for video streaming and video processing transactions is still a time-consuming task that can reduce the network’s performance and eventually user experience.
  • three light-weight proofs designed specifically for video processing and services are proposed. These proofs are expected to reduce dramatically verification time for video streaming and video processing transactions. Summaries of examples of these proofs are as follows:
  • A.l. Artificial Intelligence
  • ResNet Deep Residual Neural Network
  • a proposed proof of storing examines only frames that are chosen by means of a secure pseudo-random function. This helps to reduce significantly validation time for storing jobs while yielding almost the same accuracy as the naive solution.
  • the proof uses Merkle Tree for data verification. For details, after a storing job is finished, witnesses pull stored video from the Content Creator and Miner, arbitrarily select a certain amount of frames from the stored videos using the aforementioned random functions, build the Merkle Tree from the chosen frames and finally compare the Merkle Tree with the Content Creator’s Merkle Tree to decide if the storing job is performed properly.
  • the “Merkle Tree” described above may refer to a data structure that can store a large amount of data via cryptographic hashes. Merkle trees make it easy to check whether a piece of data is part of the structure in a very short amount of time and computational effort.
  • a Miner node / serves a video stream to a viewer node j as a service.
  • the viewer j In return, the viewer j needs to spend its hashing power to compute watched certificates and sends back the certificates for caching at the miner node / ' regularly.
  • miner node / can terminate the video stream.
  • All watched certificates will be stored in an underlying blockchain’s ledger so that they can be verified by any node in the proposed Blockchain-based network 200.
  • the Viewer V requests to view a video stream of the Delivery Provider D.
  • the Delivery Provider D will give the Viewer V a puzzle to solve.
  • the puzzle can have multiple answers, and the answers are quantifiable in terms of how good they are.
  • the V operator is a concatenation function and T is referred as the difficulty.
  • T is referred as the difficulty.
  • the proposed Blockchain-based network of the present example does not set a default difficulty like the Bitcoin network does.
  • the Viewer V can submit any answer to a puzzle sent to the Viewer V by the Delivery Provider D. However, based on how good the answer is, the Delivery Provider D can decide how long it is going to serve the content to the Viewer V. It is obvious that Viewers that provide answers with more leading zeros would be served longer as they are likely to spend more computing resource.
  • the Delivery Provider D In order to prove to the Witness W that the Delivery Provider D actually streamed a video to the Viewer V, the Delivery Provider D just needs to provide the answers received by the Viewer V to the Witness W. These answers can be easily verified by the Witness W to determine whether the Delivery Provider D actually streamed the video to the Viewer V. If the answers provided by the Delivery Provider D match the answers provided by the Viewer V to the Witness W, it is an indication that the Delivery Provider D actually streamed the video to the Viewer V. Although video is discussed above, it is appreciated that this manner of Proof of Delivery is applicable to all types of files.
  • Video transcoding transaction i.e. one node requests another node to perform a job to transcode a video from one video format to another video format;
  • Video storage transaction i.e. one node requests another node to perform a job to store a video or segments of the video
  • Video delivery transaction i.e. one node requests another node to perform a job to deliver a video to be played at a node of a viewer.
  • Audio file transcoding transaction i.e. one node requests another node to perform a job to transcode an audio file from one audio file format to another audio file format;
  • Audio file storage transaction i.e. one node requests another node to perform a job to store an audio file or segments of the audio file;
  • Audio file delivery transaction i.e. one node requests another node to perform a job to deliver an audio file to be played at a node of a listener;
  • Transaction involving storage of one or more file other than audio or video file e.g. text file, presentation file (e.g. powerpoint file), pdf file, and the like i.e. one node requests another node to perform a job to store the one or more file or segments of each file;
  • file other than audio or video file e.g. text file, presentation file (e.g. powerpoint file), pdf file, and the like
  • Transaction involving delivery of one or more file other than audio or video file e.g. text file, presentation file (e.g. powerpoint file), pdf file, and the like i.e. one node requests another node to perform a job to deliver the one or more file to a specific node; and
  • Payment transaction i.e. one node paying tokens or crypto-currency coins to another node, for example, after one of the above jobs is done.
  • a Proof discussed above refers to a transaction verification method. Proofs similar to the 3 Proofs discussed above may be provided for the aforementioned audio file transactions, transactions for non-video and non-audio files, and for the payment transaction as well. All of these proofs should be provided“on-chain” and not“off-chain”.
  • a smart contract in examples of the present disclosure may refer to a contract that includes more than one of the above transactions.
  • a smart contract that includes both an audio file storage transaction and a payment transaction that involves the node requesting for the audio file storage paying tokens or crypto-currency coins to the node that performed the audio file storage.
  • a proposed version of Delegated Byzantine Fault Tolerance is described as follows.
  • the proposed version of the Delegated Byzantine Fault Tolerance is designed to solve the most primary concern of any decentralized video streaming platform, which is scalability pertaining to transaction validation.
  • the protocol includes three fundamental building blocks, namely, Byzantine Fault Tolerance Algorithm, a Delegated Proof-of- Stake Consensus Model and a unique Sharding Technique. Playing different roles in the Delegated Byzantine Fault Tolerance, these protocols and techniques as a whole offer a reliable low-cost mechanism to reach agreements between geographically distributed network nodes of a decentralized video streaming platform, given an insignificant number of nodes are dishonest parties. The following explains in detail the functionalities of the three mentioned components and how the proposed protocol works.
  • the proposed version of the Delegated Byzantine Fault Tolerance employs the following.
  • Delegated Proof of Stake is used to select witnesses and schedule transaction verification processes. Transactions within the proposed network are verified by selected witnesses.
  • Byzantine Fault Tolerance is used as the mechanism to reach an agreement between independent witnesses, assuming more than 66% of the witnesses are honest actors.
  • a unique Sharding technique for the proposed version of the Delegated Byzantine Fault Tolerance is utilised with a principle to divide transactions into smaller independent groups that can be verified separately by a particular sub-set of witnesses.
  • Each of the independent groups is called a shard.
  • Size of shards that is the number of transactions within a shard, is automatically adjusted to accommodate changes to the network’s load.
  • FIG. 4 shows a flowchart 400 illustrating the concept of the Byzantine Fault Tolerance.
  • the problem is originally described as follows: a group of generals 402 to 408 wishes to formulate a plan for attacking a city, the group of generals including one commanding general 402 and many lieutenant generals 404, 406 and 408, each commanding a portion of the Byzantine army.
  • the generals 402 to 408 can only decide whether to attack or retreat. Some generals 402 to 408 may prefer to attack, while others prefer to retreat.
  • the generals 402 to 408 communicate their decisions together and a consensus must be reached between them.
  • the problem is complicated by the presence of traitorous generals 408 who may not only cast a vote for a suboptimal strategy, they may do so selectively.
  • Byzantine fault tolerance can be achieved if the loyal (non-faulty) generals 404 and 406 have a majority agreement on their strategy.
  • DPoS Delegated Proof-of-Stake
  • DPoS is a variant of the Proof of Stake system, which itself was developed to solve a current scalability problem associated with Proof of Work systems, that is, the requirement of a large amount of electricity to decide the validity of blocks.
  • DPoS employs a reputation system and a continuous approval voting to achieve consensus. Further details of DPoS are as follows.
  • Transactions will be produced by top N number of witnesses of the proposed network. These witnesses can be any crypto-currency coin holder of the proposed network. Each witness can be a content creator, a miner, a system administrator of the proposed network, advertiser or any user having an account registered with the proposed network.
  • a transaction may be a smart contract agreed between two parties, for example, a content creator and a miner, in the proposed network.
  • the top N number of witnesses has a function to monitor and store transactions generated by, for example, a content creator, a miner, and/or an advertiser.
  • Each of the stored transaction has to be verified i.e. to check integrity of the transaction, for instance, by checking that a job done by a miner is according to requirement by a content creator.
  • a verified or valid transaction refers to a transaction that has been verified by a witness to be executed/done correctly.
  • Each transaction stored by a witness is verified by a witness and produced as a block by the same witness that verified the corresponding transaction or another witness assigned to produce blocks upon verification that the transaction has been executed/done correctly.
  • a produced block is thus a transaction that has been verified.
  • top N witnesses are chosen by voting and will have a ratio to produce blocks proportional to the total votes they have received relative to the other witnesses. For example, in a situation where there are three witnesses A, B and C. A number of votes that each of the witnesses A, B and C received during a voting process is as follow:
  • a block will be verified by one of the three witnesses.
  • the proposed network would then randomly choose one of the three witnesses to verify the block.
  • the probability of a witness to be chosen will be proportional to the total votes they have received relative to the other witnesses. This means the following:
  • Voters involved in the voting may be crypto-currency coin holders of the proposed blockchain- based network.
  • each block refers to a verified transaction and an aggregated block is a plurality of produced blocks. .
  • a voter s voting strength is determined by how many tokens the voter possesses. For instance, the higher the number of tokens, the more voting power the voter has. It may be that a voter can vote only if he or she has a predetermined number of tokens.
  • Tokens may be awarded to each voter upon accomplishing certain actions in the proposed network. For instance, a miner may earn tokens upon accomplishing every job requested by a content creator and a content creator may earn tokens for every job request sent to the proposed network.
  • a token may be a crypto-currency coin. Token awarding may be determined by each smart contract or transaction agreed between two nodes of the proposed network. For example, in a smart contract, a miner may be paid by tokens for performing a video transcoding, storage or delivery job for a video content creator.
  • Blocks will be produced by the top N witnesseses every pre-defined time interval, with each interval usually lasting three seconds to five seconds. Such pre-defined time interval would be periodically allocated by the proposed network.
  • a Block producer at a given time is determined using a pseudorandom function to ensure unbiased and fair distribution of transaction verification work, and to ensure that there is sufficient rotation among the witnesses to be a block producer.
  • only one producer is authorized to produce a block. If a producer misses production of a block and has not produced any block within the last 24 hours, it may be removed from consideration by the pseudorandom function until the producer notifies a controlling/managing node or nodes of the proposed blockchain-based network of its intention to start verifying transactions and producing blocks again.
  • only one witness verifies each transaction and produces the transaction as a block upon successful verification.
  • each transaction is verified by each of the plurality of witnesses, the consensus between the plurality of witnesses to produce the corresponding block for that transaction being verified is achieved using the Byzantine Fault Tolerance algorithm.
  • Such modified DPoS is herein known as the Delegated Byzantine Fault Tolerance.
  • the Delegated Byzantine Fault Tolerance uses considerably more resources than its ancestor (i.e. DPoS) as blocks are verified and produced by a plurality of witnesses.
  • a predefined time interval is periodically provided to verify transactions and at the beginning of each time interval, collection of transactions in the proposed network to be verified takes place.
  • the transactions collected are split into a plurality of independent groups of transactions. Each of these independent groups is considered as a Shard. Similar to the grouped transactions, the top N number of elected witnesses are also grouped into k number of separate subsets, with k being the number of shards.
  • Each shard comprising a plurality of transactions is to be verified by a specific witness subset.
  • Each witness will verify each transaction of each shard and the decision to produce a block for the transaction would depend on the Byzantine Fault Tolerance algorithm applied to the verification result provided by each witness in the witness subset.
  • the size of a witness subset i.e. the number of witnesses in each witness subset may be set to be proportional to a total number of transactions in the corresponding shard of the witness subset.
  • Figure 5 demonstrates a flowchart 500 of an example of how a proposed version of the Delegated Byzantine Fault Tolerance may be implemented.
  • transactions to be verified are collected within a pre-defined time interval t that is periodically provided by the proposed network (e.g. 200 of Figure 2) for transaction verification.
  • the N top witnesses (i.e. 502, 504, 506 and 508 in Figure 5) are chosen by voting. Voting strength of voters is determined by how many tokens they possess, that is their stake (e.g. crypto currency coins held).
  • the pseudorandom function described earlier may be used to decide who among the top N witnesses will be selected for the verification process for the collected transactions. Some or all of the top N witnesses may be selected for the verification process depending on the number of transactions collected.
  • the top N witnesses i.e. 502, 504, 506 and 508 in Figure 5
  • the pseudorandom function described earlier can also be used to decide whose turn to be one of the roles.
  • a proposer 502 is responsible for dividing transactions and the top N witnesses into shards and witness subsets respectively.
  • the proposer 502 also takes care of block broadcasting, block aggregation, and block production.
  • Block broadcasting is, for example, done after a block is produced.
  • Block aggregation is, for example, done to consolidate blocks produced for transactions in a shard into an aggregated block.
  • Block production is, for example, done after each transaction in a shard is verified to be correctly executed/done using the Byzantine Fault Tolerance protocol.
  • Delegates 504, 506 and 508 are each responsible for transaction verification and deciding whether a job associated with each transaction of each shard assigned to each of the delegates 504, 506, and 508 is executed/done correctly.
  • the delegates 504, 506 and 508 follow the Byzantine Fault Tolerance protocol to reach a consensus on whether the job of each transaction is executed/done correctly.
  • Dishonest witness 508 contributing to an invalid result for one or more transactions will be marked as untrusted.
  • the invalid result may for one example mean that if a majority of witnesses verifies a job relating to a transaction to be correctly done and a minority of witnesses verifies the job to be incorrectly done, the incorrectly done verification result by the minority of witnesses would be deemed as the invalid result.
  • a majority of witnesses verifies a job relating to a transaction to be incorrectly done and a minority of witnesses verifies the job to be correctly done
  • the correctly done verification result by the minority of witnesses would be deemed as the invalid result.
  • the incorrect transaction would be notified to the parties involved that initiated the transaction and the transaction would be removed from further consideration. No block will be produced for the transaction that is removed. After the removed transaction is corrected, revised or subject to terms re-negotiated by the party or parties involved, it can be broadcasted again as a transaction to be verified during another instance of the pre-defined time interval.
  • the dishonest witness 508 may not be able to participate in the verification process of a transaction permanently or for a period of time.
  • an Application Programming Interface API to determine whether a witness is dishonest. Basically, this API will redo all the transaction verifications performed by a witness to compare its results with the witness’s results to spot dishonest or erroneous transaction verifications performed by the witness. If a witness made a mistake but he/she is actually honest, he/she will receive the same treatment as if he/she is dishonest.
  • the dishonest witness 508 may lose its chance to participate in further transaction verification processes if it makes a pre-determined number of mistakes or provides a pre-determined number of dishonest transaction verification results.
  • the dishonest witness 508 may lose tokens or crypto-currency coins that it has“staked” in the network. How a witness put stakes in the network depends on the consensus model adopted. In the case that the consensus model is Proof of Stake (PoS), a node of the network voluntarily bids itself to be a validator (similar to the role of witness) that can verify transactions by placing a stake (i.e. tokens or crypto-currency coins). The highest bidders will become validators and are less likely to be dishonest because they have more stake to lose if they are dishonest.
  • PoS Proof of Stake
  • the consensus model is Delegated Proof of Stake (DPoS)
  • every node of the network has to put a stake and a voting process begins to vote for the most trusted witnesses. Voters with highest stake may have more voting power.
  • the present example adopts the DPoS approach.
  • a transaction has 66% or higher consensus among witnesses verifying the transaction to determine that the transaction is correctly executed/done, the transaction is regarded as valid and is subject to block production.
  • the transaction is regarded as invalid and is not subject to block production.
  • a block may be produced for each valid transaction and subsequently, an aggregated block may be produced for each shard to contain all the valid transaction or valid transactions from the shard.
  • time interval for transaction verification i.e. this relates to the pre-defined time interval for collecting one or more transactions to produce one or more block.
  • Q(t, n, tx) a deterministic function to select one proposer from a set of witnesses.
  • a deterministic function is one that always returns an expected result any time it is called with a specific set of input values.
  • One example of a deterministic function would be AVERAGE(a, b) which returns an average of a and b. It can be seen that given a same set of (a, b), the AVERAGE function always return an expected result, which is (a + b) / 2.
  • the method begins when a pre-defined time interval t is provided.
  • This predefined time interval t is provided periodically, for instance, one after the other, or with some breaks in between.
  • nodes of a proposed Blockchain-based network of the present example digitally sign all the transactions that they would broadcast to the entire network.
  • N number of witnesses selected by a pseudorandom function is tasked to monitor and store data of these broadcasted transactions to their data storage during the time interval t.
  • a proposer p is selected using the function Q(t, n, tx) from among the N witnesses.
  • the proposer p uses a grouping process (a grouping algorithm may be applied) to split the broadcasted transactions and the number of tasked witnesses into k independent groups, with /( being a number adjusted automatically based on the network load. Each independent group is deemed as a shard. Hence, there are k number of shards assigned to a corresponding subset of witnesses.
  • the proposer p verifies, digitally signs and broadcasts details of the k independent transaction groups assigned to their corresponding subset of witnesses.
  • delegates when delegates (made up of the N number of witnesses) receive their assigned shards and the witness subset information, they verify the correctness of the shard assignment process performed by the proposer p by re-computing the grouping process that took place at the proposer p. If the shard is verified to be correctly assigned by the proposer p, the delegates will verify transactions in their assigned shards and exchange their verification results with other delegates in the same witness subset. Using the Byzantine Fault Tolerance protocol, if a consensus is reached between delegates of the same subset, that is 66% or higher majority of the delegates agree on correct job execution/done for one or more transactions in a shard, the one or more transactions are deemed to be valid.
  • the delegates then digitally sign to the shard comprising the one or more valid transactions and broadcast the results for the one or more valid transactions of the shard.
  • Digitally signing to a shard may refer to digitally signing the shard and/or digitally signing each transaction in the shard. Such digital signing helps to track which delegate verified the shard or which delegate verified each transaction.
  • the proposer p is in charge of collecting and aggregating valid transaction results of the shards from different witness subsets assigned to the shards.
  • the proposer p listens for the broadcasted valid transaction results from the witness subset or subsets and begins block production after the time interval t.
  • Block production can be done in a few ways as follows:
  • Each valid transaction may be produced as a block and written or recorded to the proposed network and no further block aggregation is performed;
  • Valid transactions of all shards created for every predefined time interval t may be aggregated to produce an aggregated block that is associated with the predefined time interval t.
  • the block or aggregated block After a block or aggregated block is produced, the block or aggregated block would be broadcasted for digital signing by the witnesses involved in the verification of the transactions pertaining to the block or aggregated block.
  • the proposer p after receiving the k number of results for the k independent transaction groups, the proposer p broadcasts an aggregated block produced for the k number of results and every delegate involved with the aggregated block then digitally signs to the produced aggregated block.
  • Digitally signing to a block or aggregated block may refer to digitally signing the block or aggregated block and/or digitally signing each transaction in the block or aggregated block. Such digital signing helps to track which delegate is responsible for verification pertaining to the block or aggregated block. In the case that some results are missing after the time interval t, the proposer p will skip these missing results and publish or broadcast the aggregated block anyway as long as the aggregated block comprises one or more valid transactions.
  • the proposed sharding process or technique described in examples above play an important role in boosting the proposed network’s throughput as validation works are spread to a plurality of separate witness groups. This increases the degree of parallelism for block production processes and at the same time still maintain a same level of fault tolerance level as shard consensus in a subset is achieved using the Byzantine Fault Tolerance algorithm.
  • nodes of a proposed Blockchain-based network of the present example digitally sign all the transactions that they would publish or broadcast to the entire network. This may mean that each node digitally signs each transaction it publishes or broadcasts.
  • each node is configured to have its own unique key-pair which is generated using, for example, Asymmetric Cryptography algorithms such as RSA and Elliptic-curve Diffie— Heilman.
  • the key-pair contains two keys which include a public key and a private key.
  • the public key of a node will be known or publicly accessible by the other nodes.
  • the private key of node will be kept as secret and stored on the node. The private key will not be sent out to any node on the network.
  • Each transaction to be broadcasted by a node will be signed using the node's private key to produce the node's digital signature for the transaction.
  • the digital signature will be broadcasted to together with the transaction.
  • the assigned witness from the N number of witnesses uses the node's public key to verify the node's digital signature that was broadcasted together with the transaction.
  • this digital signature verification process take an example where there is a node m that has an asymmetric key-pair which includes a private key SK and a public key PK.
  • the node m uses its private key to encrypt the transaction T to produce a digital signature S for the transaction T.
  • the node m will broadcast both the transaction T and its digital signature S.
  • a witness receives the transaction T and its digital signature S, in order to verify the authenticity of the transaction T, that is, to effectively check that the transaction T is generated by the node m, the witness would use the node m' s public key PK which is publicly accessible to decrypt the digital signature S. If the output of the decryption process is the transaction T, the transaction T will be considered a valid transaction Tto be verified.
  • digital signing of transaction it is appreciated that the same digital signing process is also applicable to digital signing of a shard or transaction in the shard by a Witness after transaction verification.
  • Another witness processing a payment transaction involving pay out of tokens to a witness for a verification job may check the digital signature of the witness who did the verification job.
  • Digital signing of a shard or the one or more transaction in the shard by a witness may be optional if the produced block or aggregated block is digitally signed by the witness.
  • Digital signing of a produced block or aggregated block by a witness may be optional if a shard or the one or more transaction in the shard is digitally signed by a witness.
  • information of user (i.e. node) accounts may be stored and synced among all the nodes of the proposed network. Nodes of the proposed network may be connected to each other. Transactions of a node will be broadcast to the entire network so that every single node of the proposed network can capture changes and be aware of a current state of the network.
  • User information that may be stored and circulated may include:
  • An algorithm 1 that may be used in the proposed sharding process for finding connected components (or vertices) of an undirected graph is as follows:
  • results connected components (or vertices) of an undirected graph
  • BFS Breadth-first search
  • Depth-first search is an algorithm for traversing or searching tree or graph data structures.
  • the algorithm starts at a root node (e.g. selecting some arbitrary node as the root node in the case of a graph) and explores as far as possible along each branch before backtracking.
  • a vertex referred in the algorithm 1 can be deemed as an actor or party (an actor or party is a node in the proposed network) involved in a transaction.
  • the vertex may represent a content creator, a miner, an advertiser, a system administrator of the proposed network, and/or a user holding tokens and/or crypto-currency coins of the proposed network.
  • a vertex is reachable from a vertex u if there is a relation/connection in a transaction involving v and u.
  • vertex v is a content creator instructing vertex u, which is a miner, to transcode, store or deliver video content.
  • the transaction between vertex v and vertex u to be verified is whether the transcoding, storage or delivery job is done correctly. If the transaction between vertex v and u is verified as valid i.e. it has been proven by witnesses that the transcoding, storing or delivery had been done correctly, vertex v may pay vertex u for the work done.
  • the payment step can form part of the transaction or the payment between vertex v and vertex u can also be a separate transaction to be subject to verification that vertex v indeed paid vertex u.
  • FIG. 6 is an example of a graph 600 illustrating the proposed sharding process operating in a manner that is consistent with the algorithm 1 .
  • the plurality of vertices 602 are split into three connected group sets, which are S1 , S2, and S3.
  • Each line 604 represents a transaction between the two connected vertices 602.
  • the proposed sharding process it is configured such that the number of witnesses is greater than or equal to the number of shards. Verification time for every transaction should be about the same for each witness.
  • the shards can be identified in linear time, in terms of total transactions and edges of the graph, using either breadth-first search or depth-first search. That is, the time complexity of the proposed sharding process using either breadth-first search or depth-first search is, for instance, a function, 0(n + m), with n being the number of transactions and m being the number of edges the graph.
  • Time complexity in computer science, refers to computational complexity that describes the amount of time it takes to run an algorithm. Time complexity is estimated by counting number of elementary operations performed by the algorithm, supposing that each elementary operation takes a fixed amount of time to perform. Thus, the amount of time taken and the number of elementary operations performed by the algorithm is taken to differ by at most a constant factor.
  • Each transaction type must have its own weight indicating its average execution time, for example, validation for a storage transaction is much faster than for a transcoding transaction, so its weight must be lower than that of the transcoding transaction.
  • transaction weight indicates how fast it is to verify for a transaction type.
  • Transaction weight will be used during the process of dividing n connected components (or vertices) into k number of shards so that, in totality, workload difference between these k shards can be minimized.
  • the workload in terms of total average execution time, between shards is defined to be proportionally equal to the size of their corresponding assigned witness subset or group.
  • Extra processing steps are required to take into consideration the workload. These extra processing steps are as follows.
  • W is an array of n elements where W [i] is the total workload of transactions that belong to a connected component (or vertex) / ' .
  • Dynamic Programming can be used to divide n connected components (or vertices) into k number of shards so that, in totality, workload difference between these shards is minimized.
  • verification of transactions of one shard can be completed in about the same amount of time as another shard. This ensures that work distribution is fair.
  • n is the number of witnesses of the AIOZ network.
  • n is the number of transactions.
  • T is an array of n elements where each element 7) is a transaction.
  • W is an array of m elements where each element 121/ is a witness of the proposed network.
  • Cost refers to the transaction weight i.e. a workload indicator that is discussed earlier.
  • Dynamic programming described above can be applied to the equation (1 ) above.
  • Dynamic programming refers to both a mathematical optimization method and a computer programming method. The method was developed by Richard Bellman in the 1 950s and has found applications in numerous fields, from aerospace engineering to economics. In both contexts, it refers to simplifying a complicated problem by breaking it down into simpler sub-problems in a recursive manner. While some decision problems cannot be taken apart this way, decisions that span several points in time do often break apart recursively.
  • computer science if a problem that can be solved optimally by breaking it into sub-problems and then recursively finding the optimal solutions to the sub-problems, then it is said to have optimal substructure. If sub-problems can be nested recursively inside larger problems, so that dynamic programming methods are applicable, then there is a relation between the value of the larger problem and the values of the sub-problems. In the optimization literature, this relationship is called the Bellman equation.
  • dishonest actors i.e. dishonest witnesses
  • dishonest witnesses need to possess at least 66% of the proposed network’s stake.
  • Every transaction can be verified only by top N number of witnesses of the proposed network that has to be elected through voting by voters who may be stakeholders such as content creator, miner, advertiser, system administrator or any user having tokens or crypto-currency coins that may be awarded because of beneficial actions contributed to the proposed network.
  • voters who may be stakeholders such as content creator, miner, advertiser, system administrator or any user having tokens or crypto-currency coins that may be awarded because of beneficial actions contributed to the proposed network.
  • the integrity of the top N number of witnesses would be of a high level.
  • each witness will monitor and store transactions collected during the time interval t to its data storage. Each witness will verify/validate correctness of each transaction and broadcast the verification result to other witnesses also assigned to verify the correctness of the same transaction.
  • a transaction may be considered valid if and only if at least 66% of the number of witnesses verifying it agrees upon its validity.
  • FIG. 7 further illustrates an example of the proposed sharding process 700 described earlier.
  • Each of the 6 Users A to F are involved in a transaction.
  • User A is involved in a transaction 7x7 that involves User B being a receiver of something from User A.
  • User B is involved in a transaction 7x2 that involves User C being a receiver of something from User B.
  • User C is involved in a transaction 7x3 that involves User D being a receiver of something from User C.
  • User D is involved in a transaction 7x4 that involves User A being a receiver of something from User D.
  • User E is involved in a transaction Tx5 that involves User F being a receiver of something from User E.
  • User F is involved in a transaction Tx6 that involves User F being a receiver of something from User E. What is sent or received between the Users can be defined according to the transaction. For instance, in the case of transaction Tx6, User F may be expecting to receive work done, for example, a video transcoded by User E.
  • each of the transactions 7x7 to Tx6 are broadcasted by each of the User A to F during a pre-defined time interval that is allocated by the proposed network.
  • witnesses W1 , W2, and W3 selected from a plurality of top elected witnesses are tasked to conduct the verification and they would be monitoring the transaction broadcasts and would be storing the transaction broadcasts as verification work to be done.
  • the pre-defined time interval is repeated periodically to receive one or more transactions to be verified.
  • One of the selected witnesses which may be W1 , W2, W3 or yet another witness, may be tasked as a proposer to group the broadcasted transactions into shards and assign witnesses to verify transactions of each shard.
  • Each witness is selected using a pseudorandom function from the plurality of top elected witnesses that have been voted by voters to be elected witnesses.
  • Each voter may be users of the proposed network with sufficient stakes, for example, holders of a predetermined quantity of tokens or crypto-currency coins, or voters may be users of the proposed network that have higher voting power for more tokens held.
  • a step 1 is performed.
  • the proposer groups each shard such that actors or parties that have no transactions with one another are not grouped together. Only actors or parties that have transactions with one another are grouped together.
  • Flence Users A to D with transactions with one another are grouped as a shard 1 and Users E and F with transactions with each other are grouped as a shard 2.
  • the arrows in the lines drawn in Figure 7 for shard 1 and shard 2 are indicative of which user is a receiver of something from another user.
  • the proposer assigns witnesses to commence verification of each transactions of each shard. For example, W1 and W2 are tasked to verify all transactions of shard 1 and W3 is tasked to verify all transactions of shard 2. A transaction is deemed valid if it is verified to be executed or done correctly. A decision on the validity of the shard can be made depending on the validity of the transactions in the shard that is determined by the assigned witnesses.
  • the Byzantine Fault Tolerance protocol can be applied to check that there is at least 66% majority of the witnesses verifying each transaction in a shard as valid before a decision is made that the shard is valid.
  • the verification process for each transaction that is performed by each witness may, depending on the job related to each transaction, be performed according to one of the 3 proofs i.e. Proof of transcoding (for validating video transcoding job), Proof of Storage (for validating video content storage job), and Proof of Delivering or Delivery (for validating video content delivery job) described earlier.
  • the network latency of the proposed sharding process or technique compared to other Blockchain-based network for Ethereum, Bitcoin and the like is significantly decreased.
  • the proposed Sharding technique or process disclosed above can be applied to existing blockchains (e.g. Ethereum) as well and not just applicable to the proposed network that is described herein.
  • existing sharding technique used in Ethereum can be replaced by the proposed Sharding technique or process.
  • a content creator 802 uses a user device to SUBMIT a job request to the proposed blockchain-based network 810 and deposits funds, tokens or crypto-currency coins to cover the cost of the job.
  • the user interface enable for the content creator 802 to send such request.
  • This deposit of funds, tokens or crypto-currency coins can be refilled at any point, but the one or more miners 804 may stop work if the deposit runs out as they gradually cash in for the work done.
  • the deposit may also include a sum payable to sign up as the content creator 802.
  • the proposed network 810 is made up of a plurality of nodes. Each user device of each witness 806 is a node in the proposed network 810. Each of the user device of the content creator 802 and the one or more miner 804 is also a node of the proposed network 810. The deposits mentioned above may be stored in one of the nodes.
  • a job’s details to be filled in by the content creator 802 may include one or more of the following.
  • Job type The Job type to be indicated by the content creator 802 can, for example, be one of Transcoding, Storing or Delivering. In the example of Figure 8, the job requested by the content creator 802 is to transcode video content.
  • Job Parameters The content creator 802 can attach related configurations for a job. Take a Transcoding job for example, a Transcoding job can have encoder configuration parameters, like resolution, bitrate and codec.
  • Miner criteria serve as a miner filter.
  • the content creator 802 may specify preferred miners’ qualifications for a job.
  • miner criteria can include Central Processing Unit/Graphical Processing Unit (CPU/GPU) configurations, bandwidth or pricing and job history (number of successful jobs, total streams and/or number of stored video contents)
  • Preferred price/video segment The content creator 802 may indicate its preferred price and number of video segments to be created, stored, delivered to one or more viewers, and/or transcoded by the miner.
  • Each video segment refers to small equally playable video file of the Content Creator’s 802 video content. Small playable video segments can be easily processed and run on low-end devices and help to increase parallelism of video processing and services.
  • Each video segment contains a fraction of the full video content.
  • Each video segment may have the fields/formats as described in Table I above.
  • Segment size of the specified by number of video segments to be created, stored, delivered to one or more viewers, and/or transcoded. Segment size may, for example, be indicated in Mega-Bytes (MB) or Giga-Bytes (GB).
  • MB Mega-Bytes
  • GB Giga-Bytes
  • each of one or more Miner 804 sends an OFFER for a job using a user device.
  • the one or more miner 804 may each deposit funds if the miner 804 needs to employ other miner’s help and the deposit would be provided to cover for the other miner’s job. To employ other miner’s help, the miner 804 would have to SUBMIT a job request with details described above as well.
  • the deposit may also be a sum payable to sign up as a miner 804.
  • An offer sent by the one or more miner 804 may include one or more of the following.
  • Miner s computing capability such as CPU/GPU details.
  • the one or more miner 804 may indicate its preferred price and number of video segments it is able to store, create, deliver to one or more viewers and/or transcode.
  • the content creator 802 picks the most suitable offer or offers according to its needs.
  • the content creator 802 sends an ACCEPT notification to the chosen one or more miner 704 that may include one or more of the following.
  • Networking Information of the content creator 802 which may include the content creator’s Public IP address and/or Private IP address of the user device used by the content creator 802.
  • the user device may be a desktop/laptop computer, a smartphone, a smart tablet device, video game console, smart television, television box (e.g. Android TV box) and the like.
  • the Networking Information of the content creator 802 may be encrypted by a public key (e.g. the public key based on Public key infrastructure (PKI)) of the chosen miner 804.
  • PKI Public key infrastructure
  • the chosen miner 804 upon receiving the ACCEPT notification from the content creator 802 at the step 3, the chosen miner 804 sends an ACKNOWLEDGE message that includes one or more of the following information.
  • Networking Information of the chosen miner 804 which may include the miner’s Public IP address and/or Private IP address of the user device used by the chosen miner 804.
  • the user device may be a desktop/laptop computer, a smartphone, a smart tablet device, video game console, smart television, television box (e.g. Android TV box) and the like.
  • the networking information of the chosen miner 804 may be the same as the networking information of the content creator 802 in the ACCEPT notification.
  • the networking information of the chosen miner 804 and the content creator 802 is necessary for later phases where the networking information is used in a process of setting up and controlling Peer-to-peer (P2P) communication sessions (e.g. established using Transport Layer Security (TLS)) between the content creator 802 and the miner 804.
  • P2P communication sessions may be known as a signaling process.
  • all networking Information stored at a user device of the content creator 802 is encrypted by a public key of the content creator 802 to provide a high level of privacy, that is, only the content creator 802 who has the corresponding private key can read the networking information.
  • a Smart Contract between the content creator 802 and the chosen miner 804 is established for the job requested by the content creator 702.
  • the smart contract includes a video transcoding transaction requested by the content creator 702 to the chosen miner 804, and a payment transaction for payment of funds, token or crypto-currency coins by the content creator 702 to the chosen miner 804. Both the video transcoding transaction and the payment transaction are to be subjected to transaction verification upon completion of each transaction.
  • the content creator 802 and the chosen miner 804 establish a P2P communication connection by means of exchanged Networking Information stated in the aforementioned ACCEPT notification and/or ACKNOWLEDGE message.
  • the job requested in the present example is to transcode video content provided by the content creator 802
  • the content creator 802 streams its video content to the chosen miner 804 for transcoding via the P2P communication connection.
  • the video content may be streamed together with a digital signature of the content creator 802. This digital signature can be verified to confirm that the video content is provided by the content creator 802.
  • the chosen miner 804 performs the job indicated under the Job Type specified in the job request of the content creator 802.
  • the chosen miner 804 broadcasts its completed video transcoding transaction to the proposed blockchain-based network 810 for verification during a pre defined time interval t that is allocated for such broadcasting.
  • the verification involves checking whether the completed video transcoding transaction is done according to the job requirements set out by the content creator 802. In the present example, verification of such broadcasted transaction is done periodically by a number of selected witnesses from N number of elected witnesses 806. The selected witnesses may be selected from the N number of elected witnesses 806 using a pseudorandom function.
  • Each elected witness is a top witness that is elected through voting by voters.
  • the voters may the content creator 802, miner 804, advertiser, system administrator of a controlling/managing node of the proposed network 810, or any user having tokens or crypto-currency coins that may be awarded because of beneficial actions contributed to the proposed network 810.
  • the proposed network 810 is configured such that, in a first step, witness selection from the N number of elected witnesses 806 takes place. In a second step, a timer for the pre-defined time interval t is started. During the pre-defined time interval f, each of the plurality of nodes of the network digitally signs and broadcast their transactions to the entire network (e.g.
  • a block production process takes place for the collected transactions according to verification results of the collected transaction.
  • the proposed network 810 is configured such that these three steps are repeated periodically.
  • the block production process may take place according to the example of the method of performing the proposed version of the Delegated Byzantine Fault Tolerance that is described previously.
  • each selected witness 806 PULLs an input stream from the user device of the content creator 802 and PULLs an output stream from the user device of the chosen miner 804.
  • the input stream can be a streaming of original video content to be transcoded by the miner 804 that is requested by each verifying witness 806 from the content creator 802.
  • the output stream can be a streaming of a video transcoded by the miner 804 that is requested by each verifying witness 806 from the chosen miner 804.
  • the original video content and transcoded video may be downloaded by each selected witness 806 instead of streamed to the user device of each selected witness 806.
  • the verification of the transactions performed during the block production process may be performed according to the three light-weight proofs i.e. Proof of Transcoding, Proof of Storage and Proof of Delivery described earlier.
  • the content of the transcoded video and original video content are checked using Artificial Intelligence to determine whether they are similar in content. If the content of the transcoded video and original video content are similar in content, the transaction is validated and the job is verified to be correctly done. If the content of the transcoded video and original video content are dissimilar, the transaction is invalidated as the job is incorrectly done.
  • a proposer p may be selected from the elected witnesses and the proposer p collects the written validation results.
  • One or more block are then produced by the proposer p for the validated transactions.
  • a block may pertain to one validated transaction or the block may be an aggregated block pertaining to more than one validated transactions.
  • blocks would be stored as a historical record of the proposed network 810 by all the nodes in the proposed network 81 0.
  • such blocks may be stored as a historical record of the proposed network 810 by one or more nodes in the proposed network 810 as opposed to all nodes.
  • the proposed network 810 RELEASES payment to the chosen miner 804 if the transaction between the content creator 802 and the chosen miner is deemed as valid that is, in this case, the video transcoding job done by the chosen miner 804 is done correctly.
  • One or more nodes of the proposed network 810 may be configured to manage the process of releasing funds in the deposit placed by the content creator 802 to an account of the chosen miner 804.
  • the payment release refers to the payment transaction that has to be verified by a witness as well.
  • each witness, content creator 802, or miner 804 uses a user device, it is appreciated that each witness, content creator 802, or miner 804 may actually be using a plurality of devices or be one or more servers, which are required for them to perform the kind of jobs that can be requested in the proposed network 810. For instance, one or more servers may be provided by the one or more miner 804 for the job of storing video content for delivery to viewers.
  • nodes in the proposed network 810 may be one or more servers for controlling/managing the proposed network 810.
  • Such one or more controlling/managing node may assist to manage the aforementioned fund deposits by providing an e-wallet or user account, facilitate electronic funds/token or crypto-currency transfer (e.g. Fiat to crypto-currency or vice versa) between parties, ensure security from hackers for the proposed network, store job requests, store miner offers, store acceptance notification, store acknowledge messages, store witness validations, and/or facilitate release of payment to the miner 704.
  • crypto-currency transfer e.g. Fiat to crypto-currency or vice versa
  • the apparatus for managing the proposed blockchain-based network 710 of the present example may include one or more of such controlling/managing node.
  • each node of the proposed network that is mentioned may refer to one or more user device.
  • Each user device may be a desktop/laptop computer, one or more server, and the like, or mobile device such as a smartphone, a tablet personal computer, and the like.
  • Each user device may also be a database.
  • the user device may also be a video game console, smart television, television box (e.g. Android TV box) and the like. It is understood that all the actions described in the present disclosure by each actor or party such as content creator, a miner, a system administrator of the proposed network, advertiser or any user having an account registered with the proposed network have to be performed using the one or more user device.
  • Each of the aforementioned user device may be, for example, be configured according to a processor 900 described with reference to Figure 9 as follows.
  • FIG 9 shows in detail an example of a processor 900 suitable for executing instructions or a program to perform a method of an example of the present disclosure described with reference to earlier Figures, and/or to operate an apparatus of an example of the present disclosure described with reference to earlier Figures.
  • the processor 900 may be a mobile device such as a smartphone, tablet device and the like as well. Alternatively, instead of one processor, more than one processors 900 may be deployed for the same purpose.
  • the processor 900 may comprise a processing unit 902 for processing software including one or more computer programs for running one or more computer/server applications to enable a backend logic flow, and for running the method or the methods of an example of the present disclosure described with reference to earlier Figures.
  • the processing unit 902 may include user input modules such as a computer mouse 936, keyboard/keypad 904, and/or a plurality of output devices such as a display device 908.
  • the display of the display device 908 may be a touch screen capable of receiving user input as well.
  • the processing unit 902 may be connected to a computer network 912 via a suitable transceiver device 914 (i.e. a network interface), to enable access to e.g. the Internet or other network systems such as a wired Local Area Network (LAN) or Wide Area Network (WAN).
  • the processing unit 902 may also be connected to one or more external wireless communication enabled devices 934 via a suitable wireless transceiver device 932 e.g. a WiFi transceiver, Bluetooth module, Mobile telecommunication transceiver suitable for Global System for Mobile Communication (GSM), 3G, 3.5G, 4G telecommunication systems, and the like.
  • GSM Global System for Mobile Communication
  • 3G, 3.5G, 4G telecommunication systems and the like.
  • the processing unit 902 can gain access to one or more storages i.e. data storages, databases, data servers and the like connectable to the computer network 912 to retrieve and/or store data in the one or more storages.
  • the processing unit 902 may include an arithmetic logic unit (ALU) 918, a Random Access Memory (RAM) 920 and a Read Only Memory (ROM) 922.
  • the processing unit 902 may also include a number of Input/Output (I/O) interfaces, for example I/O interface 938 to the computer mouse 936, a memory card and/or a Subscriber Identity Module (SIM) card slot or slots 916, I/O interface 924 to the display device 908, , and I/O interface 926 to the keyboard/keypad 904.
  • I/O Input/Output
  • the components of the processing unit 902 typically communicate via an interconnected bus 928 and in a manner known to the person skilled in the relevant art.
  • the computer programs may be supplied to the user of the processor 900, or the processor (not shown) of one of the one or more external wireless communication enabled devices 934, encoded on a data storage medium such as a CD-ROM, on a flash memory carrier, a Solid State Drive or a Hard Disk Drive, and are to be read using a corresponding data storage medium drive of a data storage device 930.
  • a data storage medium such as a CD-ROM
  • flash memory carrier such as a solid State Drive or a Hard Disk Drive
  • Such computer or application programs may also be downloaded from the computer network 912.
  • the application programs are read and controlled in its execution by the processor 918.
  • intermediate storage of program data may be accomplished using RAM 920.
  • one or more of the computer or application programs may be stored on any non-transitory machine- or computer- readable medium.
  • the machine- or computer- readable medium may include storage devices such as magnetic or optical disks, memory chips, or other storage devices suitable for interfacing with a general purpose computer.
  • the machine- or computer- readable medium may also include a hard-wired medium such as that exemplified in the Internet system, or wireless medium such as that exemplified in the Wireless LAN (WLAN) system and the like.
  • WLAN Wireless LAN
  • Examples of the present disclosure may have the following features.
  • a method for transaction verification in a blockchain-based network comprising: providing periodically a time interval for transaction verification for a blockchain-based network comprising a plurality of nodes, wherein each node is a user device and the following is performed for the transaction verification : broadcasting of a plurality of transactions to the blockchain-based network to be verified; generation of a plurality of shards (e.g.
  • each shard comprises a group of the broadcasted transactions; grouping of the broadcasted transactions that are inter-related into each shard; to minimise verification workload difference between shards, grouping of the broadcasted transactions into each shard according to a transaction weight associated with each broadcasted transaction and indicative of verification workload of the associated broadcasted transaction ; and assignment of more than one verification nodes (e.g. 806 of Figure 8) in the blockchain-based network to verify one or more transactions in each shard, wherein one or more block is produced for the one or more transaction in each shard that is verified to be correctly performed.
  • each verification nodes e.g. 806 of Figure 806
  • Two broadcasted transactions may be inter-related when the two transactions involve a common node in the blockchain-based network.
  • Each shard may be created by: creating a graph comprising a plurality of nodes involved in the plurality of transactions; connecting every two nodes in the graph if there is a transaction between the two nodes; selecting an arbitrary unexplored node in the graph to include into the shard; running a Breath-first search or Depth-first search to begin searching from the arbitrary unexplored node and further expanding the search by tracing connections between nodes in the graph; including into the shard each node found by tracing the connections between nodes in the graph ; and removing each node in the graph that is included into the shard.
  • a consensus model may be provided on-chain in the blockchain-based network and is applied to determine the verification result of a transaction when there is disagreement in the verification results determined by different verification nodes verifying correctness in the performance of the transaction.
  • To be“on-chain” means that the consensus model above is built into the blockchain- based protocol that the blockchain-based network is based on, and the actions pertaining to the consensus model are performed in the blockchain-based network. This is contrary to an“off-chain” solution that, for instance, requires users to utilise third party software to perform the actions pertaining to the consensus model.
  • the consensus model may be based on Delegated Proof of Stake or Delegated Byzantine Fault Tolerance.
  • the more than one verification nodes may be selected from a plurality of nodes voted by nodes in the blockchain-based network.
  • the more than one verification nodes selected may be different for each time interval.
  • Each verification node may digitally sign a shard after verification of the one or more transaction in the shard and a block comprising one or more transaction in the shard is produced.
  • Each verification node may digitally sign each transaction in a shard after verification of the one or more transactions in the shard and a block is produced for each transaction in the shard.
  • the one or more block may be produced even if each transaction in a shard is not verified during each time interval.
  • the unverified transaction or transactions in the shard may be verified in a next instance of the time interval.
  • An apparatus for transaction verification in a blockchain-based network (e.g. 200 of Figure 2 and 810 of Figure 8), wherein the apparatus comprises: a memory; a processor configured to execute instructions to operate the apparatus to: provide periodically a time interval for transaction verification for a blockchain-based network comprising a plurality of nodes, wherein each node is a user device, wherein a plurality of transactions is broadcasted to the blockchain-based network to be verified, a plurality of shards (e.g.
  • each shard comprises a group of the broadcasted transactions, wherein the broadcasted transactions that are inter-related are grouped into each shard and, to minimise verification workload difference between shards, the broadcasted transactions are grouped into each shard according to a transaction weight associated with each broadcasted transaction and indicative of verification workload of the associated broadcasted transaction, wherein more than one verification nodes (e.g. 806 of Figure 8) are assigned to verify one or more transactions in each shard, wherein one or more block is produced for the one or more transaction in each shard that is verified to be correctly performed.
  • each verification nodes e.g. 806 of Figure 806
  • Two broadcasted transactions may be inter-related when the two transactions involve a common node in the blockchain-based network.
  • Each shard may be created from a graph comprising a plurality of nodes involved in the plurality of transactions, every two nodes in the graph are connected if there is a transaction between the two nodes, the shard includes a selected arbitrary unexplored node in the graph and each node found by tracing connections between nodes in the graph, the tracing of connections between the nodes is performed by running a Breath-first search or Depth-first search that begins searching from the arbitrary unexplored node and further expanding the search to trace the connections between the nodes, and each node in the graph that is included into the shard is removed.
  • a consensus model may be provided on-chain in the blockchain-based network and is applied to determine the verification result of a transaction when there is disagreement in the verification results determined by different verification nodes verifying correctness in the performance of the transaction.
  • To be“on-chain” means that the consensus model above is built into the blockchain- based protocol that the blockchain-based network is based on, and the actions pertaining to the consensus model are performed in the blockchain-based network. This is contrary to an“off-chain” solution that, for instance, requires users to utilise third party software to perform the actions pertaining to the consensus model.
  • the consensus model may be based on Delegated Proof of Stake or Delegated Byzantine Fault Tolerance.
  • the more than one verification nodes may be selected from a plurality of nodes voted by nodes in the blockchain-based network.
  • the more than one verification nodes selected may be different for each time interval.
  • Each verification node may be configured to digitally sign a shard after verification of the one or more transaction in the shard and a block comprising one or more transaction in the shard is produced.
  • Each verification node may be configured to digitally sign each transaction in a shard after verification of the one or more transactions in the shard and a block is produced for each transaction in the shard.
  • the one or more block may be produced even if each transaction in a shard is not verified during each time interval. If all transaction or transactions in a shard is not verified by the more than one verification nodes assigned to the shard, the unverified transaction or transactions in the shard may be verified in a next instance of the time interval.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne un procédé et un appareil de vérification de transactions dans un réseau de chaînes de blocs. Le procédé consiste à : fournir périodiquement un intervalle de temps pour une vérification de transactions consistant à diffuser une pluralité de transactions au réseau de chaînes de blocs devant être vérifié; générer une pluralité de fragments à partir des transactions diffusées, chaque fragment comprenant un groupe des transactions diffusées; grouper les transactions diffusées qui sont interdépendantes les unes aux autres dans chaque fragment; afin de minimiser la différence de charge de travail de vérification entre des fragments, grouper les transactions diffusées dans chaque fragment en fonction d'un poids de transaction associé à chaque transaction diffusée et indiquant la charge de travail de vérification de la transaction diffusée associée; attribuer plus d'un nœud de vérification dans le réseau de chaînes de blocs pour vérifier une ou plusieurs transactions dans chaque fragment; et produire le ou les blocs à partir de la ou des transactions dans chaque fragment qui est vérifiée comme étant correctement exécutée.
PCT/SG2018/050380 2018-07-27 2018-07-27 Procédé et appareil de vérification de transactions dans un réseau de chaînes de blocs WO2020022957A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/SG2018/050380 WO2020022957A1 (fr) 2018-07-27 2018-07-27 Procédé et appareil de vérification de transactions dans un réseau de chaînes de blocs

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SG2018/050380 WO2020022957A1 (fr) 2018-07-27 2018-07-27 Procédé et appareil de vérification de transactions dans un réseau de chaînes de blocs

Publications (1)

Publication Number Publication Date
WO2020022957A1 true WO2020022957A1 (fr) 2020-01-30

Family

ID=69180693

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SG2018/050380 WO2020022957A1 (fr) 2018-07-27 2018-07-27 Procédé et appareil de vérification de transactions dans un réseau de chaînes de blocs

Country Status (1)

Country Link
WO (1) WO2020022957A1 (fr)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112039860A (zh) * 2020-08-18 2020-12-04 上海简苏网络科技有限公司 一种在联盟链中实现联合共识分片的方法和装置
CN112184226A (zh) * 2020-09-30 2021-01-05 中国科学院计算技术研究所 一种区块链动态分片方法及系统
CN113256417A (zh) * 2021-05-14 2021-08-13 杭州链网科技有限公司 一种基于交易共享的共识出块方法及系统
US11153358B2 (en) 2019-07-31 2021-10-19 Theta Labs, Inc. Methods and systems for data caching and delivery over a decentralized edge network
CN113922965A (zh) * 2021-10-09 2022-01-11 筹远(上海)信息科技有限公司 一种拜占庭场景下的区块链数据共识方法及装置
US11244307B2 (en) * 2019-01-02 2022-02-08 LINE Plus Corporation Transaction processing system and method enabling expansion of blockchain
US11659015B2 (en) 2019-10-11 2023-05-23 Theta Labs, Inc. Tracker server in decentralized data streaming and delivery network
US11741083B2 (en) 2020-07-24 2023-08-29 International Business Machines Corporation Cross-shard private atomic commit
US11763332B2 (en) 2020-11-16 2023-09-19 Theta Labs, Inc. Edge computing platform supported by smart contract enabled blockchain network
CN117354315A (zh) * 2023-08-29 2024-01-05 长江水上交通监测与应急处置中心 一种大跨度地域航运数据链的共识方法及系统
CN117354315B (zh) * 2023-08-29 2024-06-04 长江水上交通监测与应急处置中心 一种大跨度地域航运数据链的共识方法及系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106899680A (zh) * 2017-03-09 2017-06-27 上海亿账通区块链科技有限公司 多区块链的分片处理方法和装置
US20180145836A1 (en) * 2016-11-18 2018-05-24 Intel Corporation Technology for secure partitioning and updating of a distributed digital ledger

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180145836A1 (en) * 2016-11-18 2018-05-24 Intel Corporation Technology for secure partitioning and updating of a distributed digital ledger
CN106899680A (zh) * 2017-03-09 2017-06-27 上海亿账通区块链科技有限公司 多区块链的分片处理方法和装置

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
FYNN E. ET AL.: "Challenges and Pitfalls of Partitioning Blockchains", 2018 48TH ANNUAL IEEE /I7FIP INTERNATIONAL CONFERENCE ON DEPENDABLE SYSTEMS AND NETWORKS WORKSHOPS (DSN-W, 28 June 2018 (2018-06-28), pages 128 - 133, XP033376285, [retrieved on 20181026], DOI: 10.1109/DSN-W.2018.00051 *
KOKORIS-KOGIAS E. ET AL.: "OmniLedger: A Secure, Scale-Out, Decentralized Ledger via Sharding", 2018 IEEE SYMPOSIUM ON SECURITY AND PRIVACY (SP, 24 May 2018 (2018-05-24), San Francisco, CA , USA, pages 583 - 598, XP033377755, [retrieved on 20181026], DOI: 10.1109/SP.2018.000-5 *
LUU L. E. ET AL.: "A Secure Sharding Protocol For Open Blockchains. 2018 CCS", 16 PROCEEDINGS OF THE 2016 ACM SIGSAC CONFERENCE ON COMPUTER AND COMMUNICATIONS SECURIT Y, 28 October 2016 (2016-10-28), Vienna, Austria, pages 17 - 30, XP058299041, [retrieved on 20181026], DOI: 10.1145/2976749.2978389 *
REN Z. ET AL.: "A Scale-out Blockchain for Value Transfer with Spontaneous Sharding", COMPUTER SCIENCE , DISTRIBUTED, PARALLEL, AND CLUSTER COMPUTING, 17 May 2018 (2018-05-17), pages 1 - 12, XP033441957, Retrieved from the Internet <URL:https://arxiv.org/pdf/1801.02531.pdf> [retrieved on 20181026] *

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11244307B2 (en) * 2019-01-02 2022-02-08 LINE Plus Corporation Transaction processing system and method enabling expansion of blockchain
US11153358B2 (en) 2019-07-31 2021-10-19 Theta Labs, Inc. Methods and systems for data caching and delivery over a decentralized edge network
US11659015B2 (en) 2019-10-11 2023-05-23 Theta Labs, Inc. Tracker server in decentralized data streaming and delivery network
US11741083B2 (en) 2020-07-24 2023-08-29 International Business Machines Corporation Cross-shard private atomic commit
CN112039860A (zh) * 2020-08-18 2020-12-04 上海简苏网络科技有限公司 一种在联盟链中实现联合共识分片的方法和装置
CN112184226B (zh) * 2020-09-30 2023-09-12 中国科学院计算技术研究所 一种区块链动态分片方法及系统
CN112184226A (zh) * 2020-09-30 2021-01-05 中国科学院计算技术研究所 一种区块链动态分片方法及系统
US11763332B2 (en) 2020-11-16 2023-09-19 Theta Labs, Inc. Edge computing platform supported by smart contract enabled blockchain network
CN113256417B (zh) * 2021-05-14 2022-07-12 杭州链网科技有限公司 一种基于交易共享的共识出块方法及系统
CN113256417A (zh) * 2021-05-14 2021-08-13 杭州链网科技有限公司 一种基于交易共享的共识出块方法及系统
CN113922965A (zh) * 2021-10-09 2022-01-11 筹远(上海)信息科技有限公司 一种拜占庭场景下的区块链数据共识方法及装置
CN113922965B (zh) * 2021-10-09 2024-04-16 筹远(上海)信息科技有限公司 一种拜占庭场景下的区块链数据共识方法及装置
CN117354315A (zh) * 2023-08-29 2024-01-05 长江水上交通监测与应急处置中心 一种大跨度地域航运数据链的共识方法及系统
CN117354315B (zh) * 2023-08-29 2024-06-04 长江水上交通监测与应急处置中心 一种大跨度地域航运数据链的共识方法及系统

Similar Documents

Publication Publication Date Title
WO2020022957A1 (fr) Procédé et appareil de vérification de transactions dans un réseau de chaînes de blocs
US11075891B1 (en) Non-fungible token (NFT) based digital rights management in a decentralized data delivery network
WO2020022958A1 (fr) Procédé et appareil de vérification de transactions dans un réseau de chaînes de blocs
CN108769751B (zh) 一种基于智能合约的网络视听管理支撑系统
US11941588B2 (en) Systems and methods for blockchain virtualization and scalability
US20210297742A1 (en) Media content rights negotiation based on a protocol for management of media content rights using a distributed media rights transaction ledger
WO2021184826A1 (fr) Procédé et appareil de transfert de ressources basés sur une chaîne de blocs, ainsi que dispositif de nœud et support de stockage
US20200090143A1 (en) System, Method, and Apparatus for Online Content Platform and Related Cryptocurrency
US10839096B2 (en) Cryptographically provable zero-knowledge content distribution network
US11126659B2 (en) System and method for providing a graph protocol for forming a decentralized and distributed graph database
US11037227B1 (en) Blockchain-based decentralized storage system
US11423498B2 (en) Multimedia content player with digital rights management while maintaining privacy of users
US20170134161A1 (en) Blockchaining for media distribution
US20190213048A1 (en) Device network for incentivized mining utilizing leveraged computing resources within a block chain architecture
EP3853803A1 (fr) Enregistreur social, numérique, interopérable, de supports acheminés, intelligents, multifilières, ainsi que systèmes et procédés de conformité et paiement d&#39;actifs cryptographiques
KR101941786B1 (ko) 블록체인기술을 이용한 컨텐츠 유통 관리 시스템 및 방법
CN110570283A (zh) 基于区块链的购物方法及系统
CN112292681A (zh) 对多媒体在去中心化网络上的实时流的参与进行验证和提供补偿
US11763332B2 (en) Edge computing platform supported by smart contract enabled blockchain network
US11089051B1 (en) Preventing denial-of-service attacks in decentralized edge networks using verifiable delay functions (VDFs)
Petkanics et al. Livepeer whitepaper
Doka et al. Cloudagora: Democratizing the cloud
US20150074268A1 (en) Mediacard systems and methods
Wang et al. P2P streaming: Use of advertisements as incentives
Tan et al. Proof-of-stream: A robust incentivization protocol for blockchain-based hybrid video on demand systems

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18927936

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18927936

Country of ref document: EP

Kind code of ref document: A1