WO2020022958A1

WO2020022958A1 - Method and apparatus for transaction verification in a blockchain-based network

Info

Publication number: WO2020022958A1
Application number: PCT/SG2018/050381
Authority: WO
Inventors: Sang Nguyen; Quang Tran; Erman TJIPUTRA
Original assignee: Aioz Pte Ltd
Priority date: 2018-07-27
Filing date: 2018-07-27
Publication date: 2020-01-30

Abstract

A method and apparatus for transaction verification in a blockchain-based network, the method comprising: enabling a transaction between a plurality of nodes in the blockchain-based network to be verified, wherein each node is a user device, a verification node is configured to verify correctness in performance of the transaction and to determine a verification result for the transaction; and receiving one or more block produced after aggregation of the verification result of one or more verified transactions, wherein a consensus model is provided on-chain in the blockchain-based network and applied to reach an agreement on the verification result of a transaction being verified on the correctness in the performance of the transaction by different verification nodes, wherein each transaction to be verified is subjected to on-chain verification in the blockchain-based network by a verification node based on one of a plurality of proofing techniques provided on-chain for transaction verification.

Description

METHOD AND APPARATUS FOR TRANSACTION VERIFICATION IN A BLOCKCHAIN-BASED

NETWORK

Field

The present invention relates to a method and apparatus for transaction verification in a blockchain-based network.

Background

Present well-known Blockchain-based networks, including biggest public blockchains such as the Bitcoin Network and the Ethereum Network, have issues with scalability. Take the Bitcoin network as an example, a theoretical maximum speed for the Bitcoin network that has been circulating online is seven transactions per second. However, in reality, the Bitcoin network is achieving maximum of only three to four transactions per second. The low throughput could be explained by the fact that the Bitcoin network is configured to employ Proof of Work as its consensus model. On the one hand, the use of this protocol provides the highest level of security. On the other hand, it dramatically reduces network throughput, which refers to reduction by transaction per second (TPS). The reason is that in the protocol for the Bitcoin network, it is mandatory that transactions of the Bitcoin network are verified by each and every network participants.

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.

To address the scalability problem that is common to most Blockchain-based networks, a number of resolutions have been proposed. The first approach to mention is the use of an off-chain network in conjunction with a main-chain network. 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.

Summary

According to an example of the present disclosure, there are provided a method and apparatus as claimed in the independent claims. Some optional features are defined in the dependent claims.

Brief Description of the Drawings

Examples of the present disclosure will be better understood and readily apparent to one skilled in the art from the following written description, by way of example only and in conjunction with the drawings, in which:

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 illustrates processes performed on-chain in an example of the present disclosure.

Figure 10 illustrates processes performed off-chain that are in contrast with the processes performed on-chain illustrated in Figure 9. Figure 1 1 is a schematic diagram showing components of a processor according to an example of the present disclosure.

Figure 12 shows a graphical representation of a Merkle Tree.

Figure 13 shows examples of filter configurations for generating audio fingerprints.

Detailed Description

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. 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.

It is believed that the proposed BCB protocol will power the next generation of video applications. Section I below 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.

As the proposed network is blockchain-based, it has some generic features of a blockchain network. For instance, there is present 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. By design, 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. For use as a distributed ledger, 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. For the proposed network, 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. Once a block is recorded, the transaction data in any given block cannot be altered retroactively without alteration of all subsequent blocks. Any alteration would require consensus of the network’s majority.

A block of the proposed network may comprise the following main information:

one or more transaction identifiers;

issuer identifier, wherein 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 (e.g. a nonce for solving a puzzle; read further for explanation of puzzle).

A non-exhaustive list of alterations that may require consensus or voting of the proposed network to implement or decide is provided as follows: Changes relating to system maintenance are as follows:

Changes to fix a technical bug;

Changes to parameters of the proposed network as follows:

Awarded token or cryptocurrency coin amount for block (i.e. transaction) verification

Time interval for transaction verification that leads to block production

Block size: number of transactions to record per block

Number of witnesses to verify transactions

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);

Changes to Content moderation such as:

Takedown/Removal of content (e.g. files) distributed between nodes

Banning bad actors in the network (i.e. user accounts, nodes), wherein banning means never to accept the bad actor into the network again;

Changes to core components of the proposed network such as:

Addition or modification of Proofs for verification of transactions;

Modification to a Consensus Model applied to decide on transaction verification; Modification to the Block Structure of the proposed network; and Restoration of the proposed network’s state to one of its past state.

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.

Section I - DECENTRALIZED SOLUTION FOR VIDEO STREAMING SERVICES

A. Video trends on the rise

Nowadays, when it comes to posting content on the internet, there are a lot of options, but video content is still the most dominant choice.

Demand-side: Current video trend statistics show the following phenomenon.

Over half a billion people are watching video on Facebook every day in year 201 7/2018. Internet Video Traffic will be over 80% of all consumer Internet traffic in 4 years’ time i.e. by year 2022.

Every second, a million minutes, or almost 17,000 hours of video content, will cross the network by 2021 .

Supply-side:

Not only do more and more platforms support video content, but also an increasing number of websites are introducing live streaming features as well. Users now are able to post photographs, videos, and even go live to interact with their friends, family, and followers through social media.

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. The more immersive the live content is, the more engaged people are. For example, live streaming can be used to conduct interviews, share live events, and grant exclusive, behind-the-scenes access. The possibilities are nearly endless.

Advertisers and entrepreneurs are increasingly investing in finding new and innovative ways to reach audiences through channels involving videos. 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.

With the onset of 5G Telecommunication Network, Augmented Reality, and Virtual Reality, video will likely become the dominant choice for viewers.

B. Issues with centralized solution for video streaming services Internet video content delivery will continue to soar in popularity but current Centralized Video Infrastructures and Live Streaming provider platforms have been observed to be outdated. Nowadays, websites usually pay for Content Delivery Network (CDN) providers, or build their own CDN to ensure their content reaches users reliably.

A typical lifecycle of a video within a CDN is as follows:

a) After it is uploaded to a CDN, video contents will be transcoded into different codecs, formats, and resolutions.

b) 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.

c) Videos are usually delivered in chunks over the Internet using servers that are geographically in close proximity to consumers.

d) CDNs usually cache frequently requested contents into in-memory storage that is RAM, in order to avoid long buffering times.

The centralized nature of current video service providers introduces the following risks and challenges:

i) Single point of failure.

ii) Human resources are required to maintain high levels of availability of the CDNs’ highly distributed infrastructures.

iii) Pricing and feature sets depend on the Hosting and Content Delivery Providers.

iv) Publishers absorb the high cost of operating a CDN, leaving less revenue to pass on to content creators. There is also the challenge of high costs of transcoding, storing, distributing and delivering video to various parts of the world. This problem gets bigger with HD, 4K and higher quality video streams. Table I below shows resolution and bandwidth requirement of popular video quality standards.

C. Proposed Solution

a) Encourage users to share their unused computing power, for example, Central Processing Unit (CPU) and/or Graphics Processing Unit (GPU), available storage/in-memory space and redundant bandwidth to form a decentralized video services platform.

b) Users’ contributed resources will be used for decentralized transcoding, storing, distributing and delivering of video contents. Users are rewarded in proportion to the amount of resources that they provided.

D. Benefits of a decentralized video infrastructure

i) CPU, GPU, storage, in-memory space and network bandwidth resources are utilized. Decentralized nature gives device owners the opportunity to compete with each other to earn rewards by providing their idle resources for the transcoding process and CDN services.

ii) 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.

iii) The ability to scale infinitely to meet the bouncing demand of consuming video streams.

iv) Some level of freedom from censorship and content restrictions.

E. Mission of the proposed Blockchain-based Protocol a) A decentralized peer-to-peer network that can offer improved video delivery at lower costs.

b) Decentralized app-enabled: video platforms and content providers can build specialized Decentralized Applications (DApps) for their audience.

Table II below provides a comparison between a centralized platform and a decentralized platform. The decentralized platform is being proposed in the present disclosure.

Section II - PRINCIPAL COMPONENTS OF A VIDEO STREAMING INFRASTRUCTURE

Modern cloud video streaming infrastructures like YouTube, Netflix, Hulu, Twitch and Amazon Video have very similar architectures. 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.

1 . 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. As such, before 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. Nowadays, a typical video services platform needs to support RTMP, HLS, 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. 2. Content Delivery Network (CDN) 106:

After a video source 102 is transcoded into different codecs, formats and resolutions, CDNs 106 store and distribute these transcoded videos to their distributed infrastructure for later consumption.

Depending on the devices’ requirements, capacities and users’ network bandwidth 1 14, 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. With the increase of use of high-end devices e.g. 1 18, 120 and 122 that prefer high-end contents, for example, 4K and HD videos, and the dominant popularity of video content, more storage, in-memory space, and broadband are required to maintain a good user experience.

Section III - ARCHITECTURE OF A DECENTRALIZED VIDEO STREAMING NETWORK

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.

Although 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.

With reference to Figures 2 and 3, there are four roles in the proposed network 200, content creators 202, miners 204, 208, 210 and 212, viewers 214 and advertisers 302.

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, 21 0 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. Specifically, 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.

With reference to both Figures 2 and 3, the miners 204, 208, 210 and 212 can get paid by content creators 202, advertisers 302 and viewers 214.

Specifically, 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 21 0 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

214.

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.

There may also be another ads-inclusive mode in which miners 208, 210 and 212 can embed ads into video content that the miners 208, 21 0 and 212 serve to viewers 214. In such ads-inclusive mode, the advertisers 302 may be the ones who pay for such run-time advertisements (ads) that are embedded into the video content. Specifically, 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.

Specifically, 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. Through the ads, 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.

For the proposed Blockchain-based network 200, 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. In order to distribute the video segments among nodes, 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. Other details that are required for creating a job would be described later with reference to Figure 8. After receiving the job request, miner nodes (e.g. 206 of Figure 2) of the proposed network 200 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. From a set of received offers, 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.

In one example, 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.

In one example 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. Generally, in a centralized environment, videos are each fully replicated to different data centers, which are located in a number of geographical regions. When a user requests a video stream, the user will be directed to a closest data center and the video stream will be served primarily by one machine of the data center. In contrast, in one example of the proposed network 200, which is a decentralized environment and not a centralized environment, a principal unit of video streaming may be a video segment and not a full video like the case of the centralized environment. Of course, 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. In one example, 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:

1 ) a list of the video segments of the requested video;

2) storage information of each video segment, such as which one or more node is storing each video segment; and 3) 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. Hence, 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. Such system design increases degree of parallelism and facilitates decentralization of video services.

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. On 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. 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. By considering internet speed of each viewer 214, the adaptive streaming feature will recommend the most optimal display resolution, R1 , to play the video. Then, 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. 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. For 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. Furthermore, in case that the closest node to the viewer is overloaded or down, the failover mechanism enables the video segment to be streamed from the next closest node.

Although video is mentioned above, the same segmentation technique is applicable to the storage and delivery of audio file or any type of file, including text file, presentation file (e.g. powerpoint file), pdf and many more.

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.

1 ) Proposed Consensus Model and a Verification Mechanism involving 3 Proofs:

In order to provide an infrastructure that facilitates real-time video streaming and processing features, 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. Such 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. However, 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. As a further enhancement, 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:

i) Proof of Transcoding for validating video transcoding jobs of the proposed network:

This proof addresses a problem in validating correctness of the proposed network’s transcoding jobs, specifically, how one can explicitly validate content of any transcoded video to determine whether the transcoded video matches with the original video or not. An Artificial Intelligence (A.l.) solution is proposed. Such A.l. solution leverages breakthrough Deep Learning technology, for example, Deep Residual Neural Network (ResNet) in combination with Metric Learning. This will significantly improve both accuracy and execution time of the proofing process. This proposed A.l. approach achieves outstanding performance against traditional baseline methods with a margin of 5-20 times faster, while preserving robustness on accuracy over various kinds of test cases. More details on the A.l. approach will be described later.

ii) Proof of Storing for validating video content storage jobs of the proposed network:

Instead of comparing frame-by-frame, which is known as a naive approach to verify whether a stored video is exactly matched with the original one, 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.

iii) Proof of Delivering or Delivery for validating jobs of the proposed network that relate to video content delivery to viewers:

This is used when a miner wants to prove to a challenger that he actually delivered a video stream to a viewer. The Proof of Delivering works as follows.

A Miner node / serves a video stream to a viewer node j as a service.

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.

If viewer j stops sending watched service certificates, 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.

To illustrate how the Proof of Delivering or Delivery works, a situation where there are three actors, a Viewer V, a Delivery Provider D (e.g. a Miner or Content Creator), and a Witness W will be described as follows.

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.

One example of this kind of puzzle would be the puzzle that is typically employed in the Proof of Work of existing Blockchain network or systems. The puzzle provides users a string X and asks them to find a nonce N such that Y = Hash(X + N) will have T leading zeros. Note that the V operator is a concatenation function and T is referred as the difficulty. On the basis of the fact that higher T equals more challenging, a comparison can be made on the“goodness” between answer, that is, answers with more leading zeros are better than those with fewer ones.

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. 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.

As regards the security of the Proof of Delivering or Delivery, ultimately, all attacks will reach a point where it is essential for fraudulent actors to consider whether their attacks are beneficial, that is, the difference between the computational cost to calculate answers and the reward to deliver a video stream. With the adopted approach of the proposed Blockchain-based network, it is strongly believed that it is highly possible to make the mentioned attack become economically infeasible.

It should be appreciated that the 3 Proofs described above are examples of Proofs that may be applied to verify transactions of the proposed network. Other methods of conducting the aforementioned Proofs are also possible.

From the examples above, the transactions that may be verified using the 3 Proofs are summarised as follows:

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; and

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.

However, other transactions that can also be verified in the proposed network are as follows: 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;

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.

The above list is non-exhaustive.

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. For example, there may be 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.

2) Proposed version of Delegated Byzantine Fault Tolerance:

A proposed version of Delegated Byzantine Fault Tolerance according to an example of the present disclosure 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.

Given the nature of video streaming processing tasks and services, which are computationally expensive to perform and time-consuming to verify, a consensus protocol that offers extremely low transaction time is desirable for such described decentralized video streaming network to be feasible. The difficulty primarily lies in the fact that there is no way to validate a video streaming processing task, except by redoing the task from start to finish. Take the transcoding task described earlier as an example, to decide whether the task is done properly, a verifier needs to:

• have access to the input video, its corresponding transcoded file and the transcoding parameters;

• re-transcode the input using the parameters; and

• compare his own output and the considered output.

Recognizing the bottleneck, the proposed Blockchain-based network applies A.l. to speed up the transaction verification progress. However, this enhancement is not practically sufficient as transaction verification for video streaming processing tasks and services is still costly to perform if the incorrect consensus models are used. To clarify that, take the current most popular consensus protocol for existing blockchain networks, which is Proof of Work, as an example. To confirm, for instance, a transcoding transaction using this protocol, the transaction needs to be re-done by each and every node in the blockchain network. This leads to a tremendous waste of computing resource, given video streaming processing tasks and services are costly jobs. Furthermore, high level of security, stemming from the characteristic of the consensus model i.e. Proof of Work, reduces dramatically network throughput, that is transaction per second (TPS). To tackle the scalability problem, one implementation involving Delegated Byzantine Fault Tolerance is proposed. It is a fast and efficient consensus protocol suitable for decentralized video streaming platforms.

In more detail, 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.

The following paragraphs discuss in detail the proposed version of the Delegated Byzantine Fault Tolerance, in particular, providing further explanation on Delegated Proof of Stake, Byzantine Fault Tolerance, and the unique Sharding technique.

With reference to Figure 4, Byzantine Fault Tolerance is the resistance of a fault-tolerant distributed system and is derived from the Byzantine Generals’ Problem where actors must agree on a concerted strategy to avoid catastrophic system failure, but some of the actors are unreliable. Figure 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. In that case, Byzantine fault tolerance can be achieved if the loyal (non-faulty) generals 404 and 406 have a majority agreement on their strategy. In more details, to reach an agreement between loyal generals 404 and 406 in the presence of m dishonest generals 408, there are:

• at least 3m + 1 loyal generals (i.e. 404 and 406);

• at least 2m + 1 communication paths (i.e.‘A’ and‘B’ paths in Figure 4, wherein Έ’ paths relate to dishonest input); and

• 2m + 1 round of exchanging messages.

With regard to the Delegated Proof-of-Stake (DPoS) adopted for the proposed network (e.g. 200 of Figure 2), it can be said that 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. Under the hood, 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.

In the present disclosure, 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.

These 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: 4

• B: 8

• C: 16

As an example, if Delegated Proof-of-Stake consensus model is applied, 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:

• The probability of the witness A to be chosen to verify the block is [4 / (4 + 8 + 16)] ^* 100

• The probability of the witness B to be chosen to verify the block is [8 / (4 + 8 + 16)] ^* 100

• The probability of the witness C to be chosen to verify the block is [16 / (4 + 8 + 16)] ^* 100

Voters involved in the voting may be crypto-currency coin holders of the proposed blockchain- based network. In the present disclosure, 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 Witnesses 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.

In the present example, 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.

In the example stated above, only one witness verifies each transaction and produces the transaction as a block upon successful verification. In another example of the present disclosure, to increase the security level for the DPoS system, it is proposed to have an aggregated block that is produced after verification of a plurality of transactions by a plurality of witnesses instead of just one witness verifying one transaction. That is, 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.

Flowever, the Delegated Byzantine Fault Tolerance provides a higher fault tolerance level in terms of network consensus, that is [f = (n - l)/3j with n being the number of witnesses. On the other hand, 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.

Flence, in another example of the present disclosure, to improve the scalability of the Delegated Byzantine Fault Tolerance, a proposed unique Sharding technique is employed.

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.

Firstly, 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.

Thereafter, the collected transactions will be verified by the top N witnesses (i.e. 502, 504, 506 and 508 in Figure 5) of the proposed network using Byzantine Fault Tolerance protocol.

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.

For every verification process done for transactions collected within each predefined time interval f, the top N witnesses (i.e. 502, 504, 506 and 508 in Figure 5) involved take turns to play following roles. The pseudorandom function described earlier can also be used to decide whose turn to be one of the roles.

Role 1 - Proposer 502

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.

Role 2 - Delegate 504, 506 and 508

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. Likewise, if 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. In the case that the transaction is truly incorrectly done, 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.

Once identified, the dishonest witness 508 may not be able to participate in the verification process of a transaction permanently or for a period of time. In one example, there is present 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. In the case that 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.

Applying the Byzantine Fault Tolerance protocol, if 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. On the other hand, if a transaction does not have 66% or higher consensus among witnesses verifying the transaction to determine that the transaction is correctly executed/done, the transaction is regarded as invalid and is not subject to block production. In one example, 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.

If, for some reason, all transactions in a shard are not verified by selected witnesses assigned to the shard within an instance of the predefined time interval f, new witnesses would be selected and the proposed network starts a new round of verification for the transactions in the shard in a next instance of the predefined time interval t.

An example of a method of performing the proposed version of the Delegated Byzantine Fault Tolerance is described as follows.

The definition of variables of the proposed version of the Delegated Byzantine Fault Tolerance is as follows.

• f: 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.

• n: number of witnesses.

• tx: number of transactions for producing an aggregated block comprising blocks produced for the number of transactions.

• 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. During the time interval f, 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. Upon selection of the proposer p, in the present example, 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 k 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. Subsequently, the proposer p verifies, digitally signs and broadcasts details of the k independent transaction groups assigned to their corresponding subset of witnesses.

In the present example, 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:

a) Each valid transaction may be produced as a block and written or recorded to the proposed network and no further block aggregation is performed;

b) Valid transactions of a shard are produced as an aggregated block; or

c) 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.

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.

In the present example, 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.

After block production for each time interval t is completed, a new time interval t would begin for collection of transactions for verification to produce further blocks and/or aggregated blocks. Fresh witnesses will be selected using the pseudorandom function for the production of the further blocks.

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.

It was mentioned earlier that during the time interval t, 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.

Specifically, 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.

During the verification process of a transaction broadcasted by a node, 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. To illustrate 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. To broadcast or publish a transaction G, the node m uses its private key to encrypt the transaction T to produce a digital signature S for the transaction T. Then, the node m will broadcast both the transaction T and its digital signature S. When 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.

The above describes 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. Likewise, 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.

For the proposed network discussed, 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:

• Node Identifier (ID)

• Transaction history

• Funds/Token/Crypto-currency Balance

• Public IP Address

• Computing, Storage, and Bandwidth Capacity

• Job History

• Contents that a node is storing

The list above is non-exhaustive.

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:

Data: vertices, edges

Result: results: connected components (or vertices) of an undirected graph;

while there are still unexplored vertices in a plurality of vertices do {

create a group set S;

choose an arbitrary unexplored vertex, and put it in S;

run BFS(Breadth-first search)/DFS(Depth-first search) from that arbitrary unexplored vertex, and with each connected vertex found, remove the found vertex from the plurality of vertices and add the found vertex to S;

add S to results·,

return results ;}

end

Breadth-first search (BFS) is an algorithm for traversing or searching tree or graph data structures. It starts at a tree root (or some arbitrary node of a graph, sometimes referred to as a 'search key'), and explores all of the neighbor nodes at a present depth prior to moving on to the nodes at the next depth level.

Depth-first search (DFS) 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.

With reference to algorithm 1 above and Figure 6, the proposed sharding process can be described as a connected component problem of an undirected graph in graph theory field.

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. For example, 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 v is reachable from a vertex u if there is a relation/connection in a transaction involving v and u. For example, vertex v is a content creator instructing vertex u, which is a miner, to transcode, store or deliver video content. In this case, 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.

Figure 6 is an example of a graph 600 illustrating the proposed sharding process operating in a manner that is consistent with the algorithm 1 . There is present a plurality of vertices 602. As explained above, each vertex is deemed as an actor or party in a transaction. The plurality of vertices 602 are split into three connected group sets, which are S1 , S2, and S3. There are lines 604 connecting every two vertices 602 indicating that there is a relation/connection between the two vertices 602. Each line 604 represents a transaction between the two connected vertices 602.

As can be seen in the lines connecting the vertices 602 in Figure 6, it is deliberately configured such that the vertices in one group cannot be reached by the vertices in the other groups. In the proposed sharding process, these groups S1 , S2 and S3 are each considered as a shard. With such configuration, 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. Such grouping helps to identify inter-related transactions and the actors or parties involved and facilitates spotting of trends and relationships between the actors or parties in the proposed network. Generally, two transactions are inter-related when the two transactions involve a common node in the proposed network.

For 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. Hence, 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.

In the example of the proposed network (e.g. 200 of Figure 2), there are different kinds of transactions, namely, transcoding, storage and delivering. Transaction types are different from each other in terms of their execution time. In order to achieve highest level of parallelism, that is, to maximize the network’s throughput, the following constraints need to be considered during the sharding process.

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. Hence, 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.

After using breadth-first search or depth first search to achieve n connected vertices of the graph (see Algorithm 1 ), let W be an array of n elements where W [i] is the total workload of transactions that belong to a connected component (or vertex) /^'. In this manner, 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. In this manner, 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.

Below is a mathematical interpretation of the sharding problem that is to be solved by the proposed sharding process. The parameters involved are as follows.

n is the number of witnesses of the AIOZ network. m is the number of transactions.

Tis 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.

Twill be divided into k independent shards S, with k - 1 > / > 0.

M indicates the shard to which the transaction T_/belongs, that is, M₀ = 2 means the transaction T₀ belongs to the shard S₂.

C_j is the estimated cost for the witness l/l/)to verify the transaction 7), n - 1 > /> 0 and m - 1 ³ j > 0. Cost refers to the transaction weight i.e. a workload indicator that is discussed earlier.

The problem to solve is how to divide l/l/ into k independent sets of witnesses such that total of workload difference between these k sets of witnesses is minimized. Let N, indicates the shard to which the witness W, belongs, that is, N₀ = 1 means the witness W₀ belongs to the shard Si , the workload Q,of the witness set / is thus defined as follow:

Equation (A):

Dynamic programming described above can be applied to the equation (A) above. Specifically, Dynamic programming refers to both a mathematical optimization method and a computer programming method. The method was developed by Richard Bellman in the 1950s 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. Likewise, in 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.

Considering the security of the proposed version of the Delegated Byzantine Fault Tolerance, in order to have a fraudulent transaction or successfully fraudulently altered data record, dishonest actors (i.e. dishonest witnesses) need to possess at least 66% of the proposed network’s stake.

However, 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. Hence, the integrity of the top N number of witnesses would be of a high level.

Furthermore, among the top N number of witnesses, there may be rotation among them and selection of different witnesses using a pseudorandom function for collected transactions to be verified during every time interval t that the transaction collection takes place. Such rotation and selection ensures unbiased and fair verification.

Moreover, consensus on verification of a transaction has to be reached between the number of witnesses conducting the verification using the Byzantine Fault Tolerance protocol. In more detail, 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.

It is evident that it is not beneficial for witnesses holding 66% or more stakes in the proposed network to manipulate the network badly. If the witnesses manipulate the proposed network badly, it would surely lower the value of their stakes as fraudulent transactions will be reported and people would be leaving the proposed network.

Figure 7 further illustrates an example of the proposed sharding process 700 described earlier. In Figure 7, there are 6 Users labelled A to F in an example of the proposed network (e.g. 200 of Figure 2) 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.

Once each of the transactions 7x7 to Tx6 are done and ready for verification/validation to check whether the jobs relating to the transactions are correctly executed or done, they are broadcasted by each of the User A to F during a pre-defined time interval that is allocated by the proposed network. During this pre-defined time interval, 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.

After the pre-defined time interval ends, a step 1 is performed. At the step 1 , 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. Hence, 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.

After sharding (i.e. creation of shards) at step 1 , in a step 2, 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. In the case that there are sufficient witnesses assigned to a shard for the Byzantine Fault Tolerance protocol to be performed among 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.

After transactions in a shard are all verified, all transactions of the shard that are verified as correctly executed/done would then be produced by the proposer as an aggregated block (i.e. a record) containing these transactions and such aggregated block would be written to the proposed blockchain-based network. Otherwise, in the case that all transactions in a shard are not verified, the transactions in the shard are subject to verification in a next instance of verification by newly selected witnesses. If one or more transaction is repeatedly found to be invalid after a predetermined number of rounds of verification by different groups of selected witnesses, the parties involved in these one or more transactions may be notified and the transaction may be removed from verification. After the transaction has been corrected, revised, or terms further negotiated by the party or parties involved, it can be broadcasted during another allocation of the predefined time interval as a transaction to be verified/validated.

The verification process for each transaction that is performed by each witness, for instance, W1 , W2 and W3 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. By virtue of a dynamic transaction-level sharding schema, that is, transactions are divided into shards after a predefined time interval that may be on the basis of their relationship and/or transaction weight, no receipt (“receipt” is a feature present in the Ethereum blockchain) is required for transactions that happen across shards. This network latency advantage stems from the fact that the proposed Sharding technique re-clusters transactions every predefined time interval t. It is noted that 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. For instance, the existing sharding technique used in Ethereum can be replaced by the proposed Sharding technique or process.

An example of a method performed by a proposed blockchain-based network 810 (e.g. similar to 200 of Figure 2) is described with reference to Figure 8 as follows.

Prior to use of the proposed network 810, all the nodes involved have to download the necessary software to enable the method to run. A user interface would be provided by the software for the nodes involved to perform the SUBMIT, OFFER, ACCEPT, and ACKNOWLEDGE functions described as follows.

At a step 1 , 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.

In the present example, a job’s details to be filled in by the content creator 802 may include one or more of the following.

1 ) 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.

2) 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.

3) Miner Criteria: Miner criteria serve as a miner filter. The content creator 802 may specify preferred miners’ qualifications for a job. For example, 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)

4) 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.

5) 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).

At a step 2, 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.

1 ) Miner’s computing capability such as CPU/GPU details.

2) Miner’s data storage space.

3) Miner’s bandwidth capacity.

4) Miner’s Job History.

5) Offering price/number of video segments: 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.

At a step 3, from a set of received offers sent by one or more miner 804, 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.

1 ) An identifier (ID) of the chosen miner. 2) An agreed price/number of video segments to be created, stored, delivered to one or more viewers, and/or transcoded.

3) 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.

For security purposes, in one example, 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. In this manner, only the chosen Miner can access the networking information of the content creator 802 using a private key of the chosen Miner.

At a step 4, 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.

1 ) The agreed price/ number of video segments.

2) 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.

In one example, 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. Such P2P communication sessions may be known as a signaling process.

In one example, 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.

After step 4, 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.

At a step 5, 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. As the job requested in the present example is to transcode video content provided by the content creator 802, after the P2P communication connection is established, 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.

At a step 6, the chosen miner 804 performs the job indicated under the Job Type specified in the job request of the content creator 802.

At a step 7, after job completion, 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 t, each of the plurality of nodes of the network digitally signs and broadcast their transactions to the entire network (e.g. the chosen miner 804 broadcasts its completed work) and the user device of each selected witness 806 collects the broadcasted transactions to be verified. In a third step, 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.

An example of how the user device of each selected witness 806 may collect the broadcasted transactions is illustrated in Figure 8. There is present in Figure 8 a step 7 in which 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. Alternatively, 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. Specifically, in Figure 8, at a step 8, the one or more selected witnesses 806 VALIDATE the video trancoding job of the chosen miner 804 using the Proof of Transcoding. According to an example of the present disclosure for the Proof of Transcoding, 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.

At a step 9, the selected witnesses that performed the verification/validation WRITE the validation results to the proposed network 810. In one example, 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. According to typical blockchain technology, such blocks would be stored as a historical record of the proposed network 810 by all the nodes in the proposed network 81 0. In another example of the present disclosure, 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.

At a step 10, 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.

Although it is mentioned above that 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.

There may be present one or more nodes in the proposed network 810 that are one or more servers for controlling/managing the proposed network 810. There may be one or more system administrator working on these controlling/managing nodes to ensure smooth performance of 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. The apparatus for managing the proposed blockchain-based network 710 of the present example may include one or more of such controlling/managing node.

More details on the 3 Proofs described earlier would be described in Sections A, B and C as follows. A. An example illustrating details of Proof of Transcoding using Artificial Intelligence for the proposed network (e.g. 200 of Figure 2 and 810 of Figure 8)

Proof of Transcoding involves comparing two videos, for instance, an original video from a content creator and a transcoded video from a miner, to see if the content of the videos are similar. If they are similar, the transaction between the content creator and the miner for the miner’s video transcoding job is deemed as valid by a witness. Otherwise the transaction is deemed as invalid.

One goal in the implementation of the Proof of Transcoding using Artificial Intelligence (A.l.) is to learn video similarity models. Deep learning A.l. technique may be used. The following describes a proposed approach that leverages features produced by the intermediate convolutional layers of a deep Residual Neural Network (ResNet) architecture to generate compact global video representation (such as feature vectors). Additionally, in order to accurately verify the similarity between two candidate videos (that is, the transcoded videos and the original one), another ResNet is trained to approximate an embedding function for distance calculation, also known as metric learning. The machine learning model is trained by iterating on batches of generated video triplets that are extracted from a development dataset. A triplet contains a set of samples including query, positive, negative videos, where the positive video is more similar to the query video than the negative one.

A.1 . Feature Extraction

Image features need to be extracted to represent video content in a compact form of information that a machine can understand, and then execute the machine learning process. Such image features extraction has to take place for training an untrained machine or untrained computer neural network to derive a model that is capable of calculating a similarity value between two (or more) videos. Such image features extraction also has to take place during use of a trained machine or trained computer neural network to extract features from two (or more) videos that are to be compared.

In the present example, features are extracted from activations of convolution layers of a pre trained ResNet. In this manner, a compact representation can be derived by Maximum Activation of Convolutions (MAC) to extract video frame descriptors.

It is appreciated that in another example, the features to be extracted to determine the video frame descriptors to be extracted can be predetermined through other suitable means and is not restricted to features extraction from activations of convolution layers of a pre-trained ResNet and derivation of a compact representation by Maximum Activation of Convolutions (MAC).

In another example, a pre-trained ResNet is not used but another suitable computer neural network is used instead. For example, other suitable deep learning neural networks include AlexNet, VGG16, GoogleNet, etc.

In the present example, for the feature extraction process, a pre-trained ResNet is employed, with a total number of l convolution layers, denoted as Forward propagating a video

frame through the network generates a total of L feature maps, denoted as

/) where s the dimension of every channel for convolution layer L, (which

depends on the frame size) and c is the total number of channels. To extract a single descriptor from every convolution layer, max pooling is applied on every channel of each feature map M^l to extract a single value. The extraction process can be formulated by Equation 1 below.

where layer vector v is a c^dimensional vector that is derived from max pooling on every channel of each feature map M^l. After extraction, all layer vectors are concatenated to obtain a video frame descriptor for the video frame. Finally, each video frame descriptor obtained in the same manner for each video frame of the input video is each normalized by applying zero-mean and ^-normalization. Thereafter, the video frame descriptors are ready for further processing to generate input of video samples to be inputted for training the model or as input of a pair of videos to the trained model for comparison of the pair of videos.

Optionally, Global video descriptors can be generated and it can be done by initially applying uniform sampling to select n frames per second for an input video, and the respective video frame descriptors are extracted for each of them. The Global video descriptors are then derived by averaging and normalizing (zero-mean and ^-normalization) these extracted video frame descriptors. A Global video descriptor describes a video as a whole. In the present example, Global video descriptors are generated as input of video samples to be inputted for training the model or as input of a pair of videos to the trained model for comparison of the pair of videos.

A.2. Metric Learning

A.2.1 . Problem Setting

An optimization problem of learning a video similarity function for the present example of proof of transcoding, especially for similarity comparison of videos content, is addressed in the present example by utilizing relative information of triplet-wise video relations.

For a given original video and a set of transcoded videos, a goal is to compute a similarity score of content between the original video and the transcoded videos in the hope that the same videos (i.e. those transcoded videos found to be the same) are ranked at the top. To formulate a process to achieve this goal, similarity between two arbitrary videos q and p can be defined as a squared Euclidean distance in a video embedding space. This can be represented by Equation 2 below.

where /ø(·) is an embedding function that maps a video to a point in an Euclidean space, Q is a system parameter, and D(·,·) is the squared Euclidean distance in this space. Additionally, a pairwise indicator function r( ·,·), which specifies whether a pair of videos are similar in content, is defined.

An objective is to learn an embedding function /ø(·) that assigns smaller distances to similar pairs compared to non-similar ones. Given an original video with feature vector v, a similar video (truly transcoded video) with v⁺ and a dissimilar video with v , the embedding function /ø(·) should map video representations to a common space $R ^d, where d is the dimension of the feature embedding, in which a distance between original v and positive v⁺ is always smaller than a distance between the original v and negative v-. This can be represented by Equation 3 below.

A distance vector indicative of the distance between the original v and positive v⁺ and the distance between the original v and negative v would be output from the trained model for further calculation to determine similarity between a pair of videos compared.

A.2.2 Triplet Loss

To implement a machine learning process of the present example, a collection of N training instances is created and organized in forms or manner of triplets G = (yy , vf, Vj ), j = 1, ...,

N , where v, , vf, vf are respective feature vectors (e.g. global video descriptors derived according to section A.1 above) of (i) a query video (i.e. original video), (ii) a positive video (i.e. truly transcoded video; also known as“similar video”), and (iii) a negative video (i.e. a dissimilar/fake video; also known as“dissimilar video”) respectively. Each triplet represents as set of sample for metric learning that contains these 3 types (i.e. (i), (ii) and (iii)) of videos. The triplets expresses or characterizes a relative similarity ranking order among the three videos, i.e., v,· is more similar to vf in contrast to vf . A hinge loss function is defined for a given triplet and it is called“triplet loss” in the present disclosure. In machine learning, the hinge loss is a loss function used for training classifiers. Equation 4 below represents this hinge loss function.

where y is a margin parameter that regularizes the gap between the distance of the two video pairs, which are to ensure a sufficiently large difference between a positive-query

distance (i.e. a distance between the original v, and positive v†) and a negative-query distance (i.e. a distance between the original v, and negative vj^~). If the video distances are calculated correctly within the margin g , then this triplet will not be penalised. Otherwise, the loss is a convex approximation of the loss that measures the degree of violation of the desired distance between the video pairs specified by the triplet.

A triplet is penalized if it does not satisfy requirements of similarity score between v, , v† , vj^~ . If a triplet is penalized, the value of the hinge loss function provided by equation (4) will be large and a batch gradient descent calculation (provided below) is required to minimize the loss. If a triplet satisfies the requirements, the value of the hinge loss function provided by equation (4) will be small and the batch gradient descent calculation (provided below) is not required to minimize the loss.

The batch gradient descent calculation that can be used to optimize an object function (i.e. the hinge loss function) is calculated using Equations 5 and 6 below.

Minimizing this loss function defined by Equation (6) will narrow the query-positive distance while widening the query-negative distance, and thus lead to a representation satisfying the desirable ranking order i.e. the transcoded videos found to be the same are ranked at the top. With an appropriate triplet generation strategy as described above in place, the resulting metric learning model will eventually learn a video representation that improves the effectiveness of video content similarity comparison for proof of transcoding.

A.2.3 Architecture

For training the metric learning model, a triplet-based network architecture is proposed for the present example. This architecture optimizes the triplet loss function of Equation 5. A computer neural network to be trained is provided or inputted with one or more set of triplet extracted from before training samples of a development database of similar and dissimilar videos. This input step is known as triplet sampling. Each set of triplet comprises a ground truth (original video), a positive video (truly transcoded video), and a negative video (fake/dissimilar video) with Vj , v†, vj^~ feature vectors, respectively. In the present example, the 3 videos are fed independently into three respective deep Residual Neural Networks (ResNet) with identical architecture and parameters. The ResNet compute the embedding functions of v : fg (v) E The architecture of the deployed ResNet is based on three dense fully-connected layers, lxl convolutional layer for reducing number of channels, and a normalization layer at the end. This leads to vectors that lie on a ^-dimension of the mapping function fg(v) that depends on the dimensionality of input vectors, which is in turn dictated by the employed ResNet architecture 106. The video embedding functions computed from a batch of triplets are then given to a triplet loss layer 108 to calculate accumulated cost based on Equation 5. As a result of the training, after-training samples outputted by the trained metric learning model would be organized in a desired manner i.e. most similar samples are ranked at the top.

In another example, ResNet is not used but another suitable computer neural network is used instead. A.2.4 Video-level Similarity Computation

In the present example, the learned embedding function fg ( - ) is used for computing similarities between videos. A feature fusion method or scheme is proposed for fusing similarity computation across video frames and it is described as follows.

Feature fusion method: Frame or video descriptors are averaged and normalized into a global video descriptor, before they are forward propagated to the neural network. The global video descriptor or signature is an output of the embedding function fg( ). Advantages of this feature fusion method are that it is computationally light and intuitive. While this method would trade-off some accuracy, this trade-off is not substantial. Finally, similarity between two videos is derived from distances of their representations.

For a given ground truth video q and a set of transcoded videos the similarity within each pair is determined by Equation 7 as follows.

where S( ·,·) is the similarity between two videos and max(') is the maximum function.

A process flow for Video-level Similarity Computation of the present example is described as follows. There are provided two videos, video 1 and video 2 for comparison. Video 1 is made up of frames V1 and video 2 is made up of frames V2. Feature vectors FV1 of the frames V1 of Video 1 may be extracted according to Equation 1 . Feature vectors FV2 of the frames V2 of Video 2 may be extracted according to Equation 1 . The feature vectors FV1 and FV2 are then subject to a matching stage that involves inputting the feature vectors FV1 and FV2 to the trained metric learning model that is trained according to the earlier description. The trained metric learning model outputs a distance vector that can be used for calculation of similarities percentage (or a similarity value) according to Equation 7.

A.2.5 Alternative approach to Metric Learning described above

In another example, an alternative approach to the Metric Learning described above can be adopted. In this example, FtesNet or other kinds of advanced Deep Learning Neural Network such as AlexNet, VGG16, GoogleNet, etc. mentioned above can be used with an FAemb algorithm (Reference:“FAemb: a function approximation-based embedding method for image retrieval”, CVPR 2015, Thanh-Toan Do, Quang D. Tran, Ngai-Man Cheung) for improving feature embedding.

An advantage of this FAemb algorithm is that this FAemb algorithm is expected to relax the requirements of triplet preparation compared to the requirements for triplet preparation for the proposed method described with reference to sections A.2.1 to A.2.4 above, while preserving the same or higher accuracy and performance. The advantage of the FAemb algorithm is based on a solid mathematical proof of feature embedding using linear approximation of a non-linear function (i.e. Taylor expansion) in high dimensional space. In one example, by applying this FAemb algorithm to a video frame after feature extraction using Resnet, it would embed the extracted feature to a high representative and discriminative space in which the similar video frames would be pretty near with each other and vice versa, without the need for using any triplet loss learning discussed in section A.2.2 above.

A.3 Audio Content Validation

A video may not only contain many frames of images but may also contain sound or audio content. For instance, a video file can be said to be a container containing video content (i.e. images only) and an audio file. Such audio content may be embedded in the video content. Such audio content also requires validation during video content validation if the video includes audio content. Examples of how the audio content can be validated are described as follows.

A.3.1 First Technique - AudioDiff

Audiodiff is a Python library for comparing audio files or streams. For example, one of the audio files to be compared may be an audio file contained in an original video file and the other audio file is a transcoded audio file contained in a video file transcoded from the original video file. To compare the two audio streams of the audio files, use the AudioDiff library to check a SHA1 checksum of an uncompressed Pulse Code Modulation (PCM) (signed 24-bit little-endian) data stream of the audio files. If the checksums of the two audio files are the same, the AudioDiff functions applied will return “true”, or “false” if the checksums of the two audio fi!es are different. The checksums can be obtained by using FFmpeg to get information of the audio and then use hashiib to compute the SHA1 checksums. Although Python is featured here, it is appreciated that other suitable tools (Mathlab) apart from Python with similar operation to perform similar checksum checks can also be used.

In the present example,“FFmpeg” refers to a vast software suite of libraries and programs for handling video, audio, and other multimedia files and streams. FFmpeg is designed for command- line-based processing of video and audio files, and is widely used for format transcoding, basic editing (trimming and concatenation), video scaling, video post-production effects, and standards compliance (SMPTE, ITU) “hashiib” is a module included in the Python Standard library containing an interface to hashing algorithms.“SHA-1” (Secure Hash Algorithm 1 ) is a cryptographic hash function which takes an input and produces a 160-bit (20-byte) hash value known as a message digest - typically rendered as a hexadecimal number, 40 digits long.

A.3.2 Second Technique - Dynamic Time Warping (DTW) & MFCC

The second technique involves first obtaining Mel-frequency cepstral coefficients (MFCCs) from each of two audio clips or files to be compared. Thereafter, Dynamic times warping (DTW) algorithm is applied to measure similarity between the sequences pertaining to the respective MFCCs derived from the two audio clips or files.

Mel-frequency cepstral coefficients (MFCCs) are derived from a type of cepstral representation of an audio clip or file. This frequency warping can allow for better representation of sound. MFCCs are calculated as follows:

- Take the Fourier transform of an audio signal to obtain a frequency spectrum

- Map the powers of the obtained frequency spectrum onto a mel-scale to obtain a Mel-Spectrum:

For example, M(f) = 1 125^*ln(1 +f/700)

- Take the logarithm of the powers at each of the me! frequencies to obtain a Me! Filterbank.

- Ceptral analysis is performed on the Mel-Spectrum to obtain Mel-Frequency Ceptral Coefficients pertaining to the audio signal.

Dynamic times warping (DTW) relates to an algorithm for measuring similarity between two temporal sequences. In general, DTW is a method that calculates an optimal match between two given sequences with certain restrictions. For example, DTW can be represented by a formula:

D(i, j) = | t{i) = r(J) \ + min{D(i - 1 , /), D{i - 1 , j - 1), D{i, j - 1)]

with an initial condition of D(1 , 1 ) = |f(1 ) 1 )r{ 1 )j

A.3.3 Third Technique - Similarities Matching using Chromaprint Algorithm

Audio signals of an audio file or clip can be represented by waveforms and spectrograms. A useful representation is in a form of a spectrogram, which shows how intensity on specific frequencies of the audio signals changes over times. For example, an audio signal may be split into many overlapping frames and the Fourier transform is applied on them (“Short-time Fourier transform”).

In the case of use of Chromaprint, an input audio signal or stream of an audio file is first converted, for example, into an audio representation having a sampling rate of 1 1025Hz with a frame size of 4096 (0.371s) and ¾noverlap. An audio image of the audio representation can be generated and image comparison can be made. Many fingerprinting algorithms work with this kind of audio representation. Some algorithms compare differences across time and frequency in the generated audio image, whereas some algorithms look for peaks in the generated audio image. However, Chromaprint processes the audio representation further by transforming frequencies into musical notes before generating an audio image for the processed audio representation. It is noted that the interest is in notes, not octaves, so a result would have 12 bins, one for each note. This information is called "chroma features" ( Audio Thumbnailing of Popular Music Using Chroma-Based Representations by Mark A. Bartsch and Gregory H. Wakefield, Journal, March 2005, IEEE Transactions on Multimedia Volume 7 Issue 1 Pages 96 - 104). fpcalc library in Python can be used for extracting Chromaprint features from an audio signal.

After some filtering and normalization of the audio representation that has been processed using Chromaprint, the resulting Chromaprint audio representation is quite robust to changes caused by lossy codecs and the like. However, the generated Chromaprint audio image of the resulting Chromaprint audio representation can still be quite hard to compare through image comparison. Also, in order to be able to search for such audio images in a database, a more compact form of the audio image is preferred.

To simplify image comparison and to enable easier search, some modifications are proposed in view of ideas taken from two papers, namely, a Computer Vision for Music Identification paper ( Computer Vision for Music Identification by Y. Ke, D. Hoiem and Rahul Sukthankar, CVPR 2005, IEEE Computer Society Conference on, Volume 2) and a Pairwise Boosted Audio Fingerprint paper ( Pairwise Boosted Audio Fingerprint by Dalwon Jang, Chang Yoo, Sunil Lee and Ton Ka!ker, IEEE Transactions on Information Forensics and Security, Volume 4, Issue: 4, Dec. 2009). For example, a 16x12 pixel large window may be provided and moved over the generated Chromaprint audio image from left to right, one pixel at a time. This will generate a lot of smaller sub-images. These sub-images may be grayscale sub-images. On each of these grayscale sub-images, a pre-defined set of, for example, 16 filters can be applied to capture intensity differences across musical notes and time. What the predefined set of 16 filters does is that they calculate a sum for each specific area or region of each grayscale sub-image. The sum here is a convolution operator calculated after overlaying each of the 16 filters over each specific area or region of each grayscale sub-image. The specific area or region can be pre-defined.

The image filtering configuration of each of the 16 filters may be selected from, for example, 6 types of image filtering configurations as shown in Figure 13. The 16 filters can be made different from one another by adjusting values of elements of a filter matrix of the selected image filtering configuration. The objective of the 16 filters is such that when applying each filter over any region or area in each grayscale sub-image, a sum for representation as part of the audio fingerprint to be obtained is calculated by calculating a convolution (weighted sum) operator. Such sum is considered to be a compact number useful for representing the audio fingerprint. Such filtering technique is also known as a way of feature extraction using multiple types of predefined filters (kernels) to extract information that are robust to noise, invariance of scale, rotation, etc.

As there are 16 filters in the present example, and each can produce an integer that can be encoded into 2 bits (using the Gray code), the combined results would thus be a 32-bit integer. If the aforementioned steps are performed for every sub-image generated by the sliding window i.e. the 16x12 pixel window, a full audio fingerprint can be obtained. Performing such filtering advantageously achieves an audio fingerprint that is more compact and easier to search in a database and is easier for comparing similarity of two audio signals.

After generating the aforementioned filtered audio fingerprints from 2 audio files to be compared, comparison to determine whether the 2 audio files are similar can be done based on matching of number of bits present in the 2 audio fingerprints. Sometimes generation of the aforementioned audio fingerprints would end up with some unwanted errors that would cause some flips in the bits compared. In fact, the probability of occurrence of a 1 bit error is rather high at 98% of the time. So, in one example, if the difference between two strings of audio fingerprint bits that are compared is just in 1 bit out of all the bits in the two audio fingerprints, it is safe to assume that the two audio fingerprints are similar. To decrease the chances of errors in the comparison, in other examples, it could be that a threshold similarity level or confidence level can be calculated. Such threshold similarity level or confidence level can be compared with a similarity value calculated for 2 audio files being compared to determine whether the 2 audio files are similar. It can be determined that the 2 audio files are similar if the similarity value is higher or lower than the calculated threshold similarity level or confidence level.

Among the three techniques A.3.1 to A.3.3 discussed above for audio file validation (i.e. similarity determination), it has been observed that similarity determination through the Chromaprint- based technique is most efficient and accurate.

B. An example illustrating details of Proof of Storing for the proposed network (e.g. 200 of Figure 2 and 810 of Figure 8)

In the present example, Proof of Storing may employ the Merkel Tree data structure which is typically used in distributed and peer-to-peer systems to ensure data integrity, that is, data received from the other peers in a peer-to-peer network are received undamaged and unaltered. This includes checking that the other peers do not lie and/or send fake data blocks. Moreover, with a purpose of network latency reduction, the Proof of Storing procedure may be configured to limit the amount of data being sent over between nodes in the proposed network and the number of computational operations to check the integrity of large data structures.

For example, a Content Creator C wants to store his video V\

1 ) C splits t/into playable video segments V= {v₁,v₂,v₃,..., v_n). 2) C submits a storing job for each segment v,·. Miners of the proposed network bid for the jobs. From a set of received offers, the Content Creator C selects the most suitable offer on the basis of their needs. From then on, each storing job v, is executed by a Miner.

3) After a chosen miner M finishes storing segment v„ one or more Witness W follows the steps a) to d) below to verify the miner’s storing job.

a) Firstly, W pulls segments v, and vi’ from the Content Creator C and the Miner M for verification respectively v, refers to the original video segment from C and vi’ refers to the stored video segment corresponding to the original video segment v,·.

b) Next, using a secure pseudo-random function, W extracts a set of arbitrary key frames from the segments v, and w' i.e.

Fi = (f J₂J₃,-, Q from v, and

Fi‘ = ( f J₂J₃,~ , fn) from vi’

c) Thereafter, W builds a Merkle Tree 7) for F, and 77 for Fi’. d) Wthen checks whether 7) equals Ti’. If T equals Ti’, W will validate Ms work for storing segment v, as correct. Otherwise, Ms work will be deemed as invalid.

Table III below provides examples of fields for the hash functions considered for the Merkle Trees. These fields in the hash functions are items that would be compared when checking whether 7) equals Ti’.

In cryptographic applications, hash functions are one-way functions, that is, typically expected to be practically noninvertible, meaning that it is not realistic to reconstruct the input datum x from its hash value H(x) alone without spending great amounts of computing time. For example, given that

between computers. It helps to ensure that data blocks received from other peers in a peer-to-peer network are undamaged and unaltered. It also can be used to check that the other peers do not lie and send fake blocks.

One benefit of organizing the data elements, which are a, b, c and d, in a Merkle Tree structure is that it becomes straightforward to verify that no received data element has been tampered with. To illustrate this usage of Merkle Tree, take, for example, that there are two parties A and B. A likes to transfer to B some data elements, which are a, b, c and d, to be stored. B likes to have a mechanism to check whether the data elements, which he receives from A, are undamaged and unaltered. That is, the integrity of the data elements is to be verified. To do so, in conjunction with the data elements, a, b, c and d, A also constructs and attaches a Merkle Tree of a, b, c and d to the package that is sent out to B to be stored. On receipt of the package, B is supposed to receive:

1 ) the data elements which are a, b, c and d\ and

2) the Merkle Tree of a, b , c and d.

In order for B to confirm that the data elements a, b, c and d that he received from A are not tampered with. S will build a Merkle Tree M₂ of the data elements, which he received, and compare with the Merkle Tree that A attached to the package. If equals M₂, it is effectively to believe that the data elements a, b, c and d are not tampered with. Otherwise, if, for example, the data element a =”1” is unintentionally changed, then, the corresponding hash values H(a) and H(ab) of the two Merkle Trees and M₂ would be different. This leads to a completely different Merkle Root H(abccf) of the two Merkle Trees and M₂, and therefore, it can be concluded that because the Merkle root were changed, one or more of data elements must have been tampered with.

Comparing the two Merkle Trees and M₂ also helps to quickly identify which data elements are damaged or altered. For example, the hash values H(abcd) and H(ab) of the two Merkle Trees and M₂ are different, however, the hash value H(ccf) of the two Merkle Trees and M₂ are the same. In this case, one can effectively conclude that either the element a or the element b is damaged or altered. In the same manner as explained above, a Witness of the proposed network would verify correctness in performance of a data storage transaction by comparing Merkle Trees of the original data and the stored data. A match would determine that the data storage transaction is correctly performed and is thus valid.

C. An example illustrating details of Proof of Delivery for the proposed network (e.g. 200 of Figure 2 and 810 of Figure 8) A fundamental building block of an example for Proof of Delivery is a Streaming Certificate. The Streaming Certificate’s goals are to serve as a Miner’s Proofs of Delivering and make abuse of miner resources, that is, a Distributed Denial of Service (DDoS) attack, infeasible. The Streaming Certificate is stored in transaction details and are verified by the Elected Witnesses (e.g. W1 to W3 of Figure 7 and 806 of Figure 8) described above during the transaction verification process that uses the Proof of Delivery. Streaming certificates are in a way similar to Bitcoin’s Proof of Work.

If a viewer j stops sending service certificates, a miner node / can terminate the video stream. Given a service certificate, the amount of time the miner’s node / would serve to the viewer’s node j can be calculated.

Equation 8 below relates to a mathematical puzzle that each viewer may need to solve in order to achieve a Streaming Certificate.

Equation (8):

nonce^* = argmin HASH(p/(,||pk_/j|blockhash_i ||segment ID||timestamp||nonce)

Equation 9 below relates to a best solution viewer j has found for the mathematical puzzle. The corresponding hash value presents the time viewer j spent to find the solution, which is equal to the time miner / serves viewer j.

Equation (9):

Other configurations of the proposed network (e.g. 200 of Figure 2 and 810 of Figure 8) described above are described below.

Although a Proof of Transcoding example using Artificial Intelligence is described above and a unique proposed Sharding Technique or Process is described with reference to Algorithm 1 , Figures 6 and 7 above, it is appreciated that the proposed network is not limited to the Proof of Transcoding example using Artificial Intelligence and/or the proposed unique Sharding Technique or Process.

The method and apparatus for managing the proposed network is based on a unique 3-layer architecture, which includes:

1 ) a high-throughput consensus model that is provided on-chain, such as the proposed version of the Delegated Byzantine Fault Tolerance that works with the proposed unique sharding technique described earlier, existing Delegated Byzantine Fault Tolerance, existing Delegated Proof- of-Stake, or existing Proof-of-Stake with Ethereum Sharding technique;

2) an on-chain solution for transaction verification/validation process that enables transaction verification/validation process to be performed within the main blockchain; and

3) a plurality of proofs provided on-chain for verification/validation of transactions.

To be“on-chain” means that the 3 layers above are built into the blockchain-based protocol that the proposed network is based on, and the actions pertaining to the 3 layers are performed in the proposed network. This is contrary to an“off-chain” solution that, for instance, requires users to utilise third party software to perform what each of the 3 layers above is targeted to do.

Specifically, on the first layer, it is optional to use the proposed version of the Delegated Byzantine Fault Tolerance that works with the proposed unique sharding technique that is described earlier. On the third layer, it is optional to use Artificial Intelligence as a proofing technique. However, a plurality of proofing techniques has to be provided to facilitate on-chain verification/validation of transactions. In an example described earlier, 3 proofs, namely, Proof of Transcoding, Proof of Storage and Proof of Delivery are proposed. Each of the 3 proofs can be used to verify and/or validate transactions relating to video transcoding, video storage and delivery of video to viewers respectively.

This 3-layer architecture can be adopted to provide a high level of transaction per second for running tasks that are expensive to perform and tasks that are time consuming to verify/validate, such as transcoding of videos. As such, the proposed network is capable of supporting video streaming and live video streaming tasks.

To show that the method and apparatus for managing the proposed network is not restricted to using a consensus model that is based only on the proposed version of the Delegated Byzantine Fault Tolerance working with the proposed unique sharding technique, an example of operation of the method and apparatus using a consensus model that is based on Delegated Proof of Stake to reach a consensus on validity of transactions is described as follows.

Nodes of the blockchain-based network are configured such that at every time interval t that is periodically allocated for broadcasting transactions, they would digitally sign their transactions and broadcast their transactions to the entire blockchain-based network.

Nodes of selected witnesses are configured to monitor and store these broadcasted transactions to their data storage during every instance of the time interval t. These witnesses may be selected from top elected witnesses that are voted by voters, which may be stakeholders holding a pre-determined stake (e.g. tokens or crypto-currency coins) or stakeholders with voting power according to amount of stake (e.g. tokens or crypto-currency coins) held in the blockchain-based network.

Among the selected witnesses, a proposer p will be selected using the deterministic function Q(t; n; tx) that was described earlier. The proposer p would employ one of the plurality of proofing methods provided by a system architecture of the blockchain-based network to verify and/or validate the transactions. Valid transactions i.e. transactions that are deemed by witnesses to be correctly executed/done will be added into a block, which is basically an accounting record containing one or more transactions. The proposer p will produce the one or more block comprising the one or more verified/validated transactions. Other selected witnesses’ nodes and/or other nodes designated for block updating that is not the node of the proposer p would be tasked to write the produced block to the blockchain-based network. To write a produced block to the blockchain-based network means to record, store and archive the block. Once a block is written, the blockchain-based network releases payment, which may be in terms of electronic cash payment, tokens or crypto-currency coins, to a party that has provided a service to an instructing party for each validated transaction.

No division of transactions into shards and assignment of witnesses to the shards that are characteristics of the proposed unique sharding technique are involved in the abovementioned Delegated Proof of Stake process. All selected witnesses will verify/validate each and every transaction received during the time interval t.

Other possible proofs that do not involve Artificial Intelligence that was proposed earlier may be used for verification of video transcoding transactions of the proposed network. Some examples are as follows.

1 ) Vanilla Proof

For example, in one video transcoding transaction of the proposed network, a Content Creator C wants a miner M to transcode his video V.

Firstly, C splits t/ into playable segments

C then submits a video transcoding job request to the proposed network for each segment v,·. Miners of the proposed network bid for the job. From a set of received miners’ offers, the Content Creator C selects the most suitable offer or offers based on his/her needs. Thereafter, each transcoding job for v, is executed by the chosen Miner M.

After the miner M finishes transcoding the segment v„ a Witness W follows the steps below to verify the miner’s transcoding job. The Witness Wdoes the following.

The Witness W first pulls segments v, and v) from the Content Creator C and the miner M respectively, wherein v,· refers to the original video segment split and supplied by C and v) refers to the transcoded video segment transcoded by the miner M.

The Witness W next extracts all frames of v,· to produce F„ wherein F, refers to extracted frames of the original video segment split and supplied by C.

The Witness W then extracts all frames of v) to produce F), wherein F) refers to extracted frames of the transcoded video segment transcoded by the miner M.

Thereafter, the Witness Wbuilds a Merkle Tree 7) for F, and a Merkle Tree Tj for F).

The Witness Wthen checks whether 7) equals T). If they are equal to each other, Wwill verify that Ms work for transcoding the video segment v, is performed correctly. The transaction is then validated. Otherwise, the transaction is invalidated.

2) An Enhanced Version of Vanilla Proof

According to the aforementioned Vanilla Proof’s specification, all frames of v, and i/, need to be extracted and then compared with each other one by one. To reduce the verification cost and time, the Vanilla Proof can be enhanced by extracting and comparing only a set of arbitrary key frames.

Details of the enhanced Vanilla Proof are as follows:

Firstly, C splits t/ into playable segments

The Witness W first pulls segment v, and v) from the Content Creator C and the miner M respectively The Witness W then extracts a set of arbitrary key frames,

from v,· and a set of arbitrary key frames,

from v) by using a secure pseudo-random function.

Thereafter, the Witness Wbuilds a Merkle Tree T for F, and a Merkle Tree F, for F).

The Witness Wthen checks whether F equals T). If they are equal to each other, Wwill verify that Ms work for transcoding the video segment v, is performed correctly. The transaction is then validated. Otherwise, the transaction is invalidated.

Figure 9 illustrates processes performed on-chain in an example of the present disclosure. In a proposed blockchain-based network similar to all instances of the proposed network described earlier, there is present a node (A) for generating one or more transaction, a Witness (B) with a job to verify transactions broadcasted in the proposed network, and a Proposer (C), which is a Witness similar to Witness (B) that is selected from a plurality of pre-assigned Witnesses that includes the Witness (B). It is understood that the node (A), Witness (B) and Proposer (C) requires a user device to perform the actions described as follows. The node (A), Witness (B) and Proposer (C) are all nodes in the proposed network.

At a step 900, the node (A) in the proposed network signs and broadcasts one or more transactions to the proposed network at the start of a time interval t.

At a step 902, the Witness (B) collects the broadcasted transactions.

At a step 903, after a time interval f, one of the plurality of pre-assigned Witnesses is selected to become the Proposer (C).

At a step 904, the Proposer (C) divides all the collected transactions into k independent transaction groups.

At a step 905, the Proposer (C) then assigns transaction groups to a number of the plurality of pre-assigned Witnesses.

At a step 906, the Witness (B) receives the assigned one or more transaction groups to be verified from the Proposer (C) and proceeds to verify the transaction division performed by the Proposer (C) at step 904. The verification is done on-chain.

At a step 907, the Witness (B) checks whether the transaction division performed by the Proposer (C) at step 904 is correct. If the transaction division is not correct, the assigned one or more transaction groups received at step 906 is ignored. If the transaction division is correct, the process goes to step 908.

At a step 908, the Witness (B) makes use of on-chain Proofs that are built-in the protocol of the proposed network to verify the transactions in the assigned one or more transaction groups.

At a step 909, the Witness (B) exchanges transaction verification results with other witnesses also assigned with the same one or more transaction groups as those assigned to the Witness (B). Thereafter, all witnesses follow a consensus model to reach an agreement on the validity of the transactions in the one or more transaction groups. A valid transaction is one in which the transaction is verified to be correctly performed.

At a step 910, once the verification results of transactions that are verified as correctly performed are out, the Witness (B) signs and broadcasts the aggregated transaction verification results. Alternatively, instead of broadcasting to numerous nodes, the Witness (B) may send the aggregated transaction verification results directly to the Proposer (C).

At a step 91 1 , the Proposer (C) receives the broadcasted aggregated transaction verification results and appends the aggregated transaction results to a to-be-produced block.

At a step 912, the Proposer (C) signs and broadcasts the to-be-produced block to all witnesses after collecting or receiving all or a predetermined number of aggregated transaction results or after the end of a predetermined time period, which may be the same amount of time as the time interval f described earlier.

At a step 913, the Witness (B) signs the to-be-produced block and sends it back to the Proposer (C).

At a step 914, the Proposer (C) publishes the block to the entire proposed network.

It should be noted that all the steps 900 to 914 described above are performed on-chain in an on-chain environment and all within the proposed blockchain-based network. No existing blockchain network has such features.

Figure 10 illustrates processes performed off-chain that are in contrast with the processes performed on-chain illustrated in Figure 9. Typically, there are 4 roles in a transaction verification process for an off-chain solution. They are a node (P) for generating one or more transaction, a Blockchain network (S), an off-chain software for users (Q) that is not part of the Blockchain network (S), and an off-chain software for Witnesses (R) that is not part of the Blockchain network (S). A witness described herein has a job to verify transactions. At a step 1001 , the node (P) delegates the off-chain software for users (Q) to access the node’s (P) account by sharing a private key of the node (P) to the off-chain software for users (Q). The node (P) may require the off-chain software for users (Q) to be installed on the node (P) or the off-chain software for users (Q) may be a server application accessible from a web page on the Internet.

At a step 1 002, the off-chain software for users (Q) stores the received private key.

At a step 1003, the node (P) then creates one or more transaction and passes them to the off- chain software for users (Q) or the off-chain software for users (Q) automatically picks up these created one or more transaction.

At a step 1 004, the off-chain software for users (Q) signs the one or more created transactions.

At a step 1005, the off-chain software for users (Q) then broadcasts the one or more created transactions to a network of witnesses that have each installed an off-chain software for witnesses (R).

At a step 1006, the off-chain software for witnesses (R) of each available witness collects or receives the broadcasted one or more created transactions.

At a step 1007, after a time interval f, the off-chain software for witnesses (R) stops collecting transactions and the off-chain software for witnesses (R) begins to verify all the received transactions using off-chain proofs to verify the correctness of the performance of the received transactions. Such off-chain proofs are again third party software that is not part of the blockchain network (S) that the verified transactions would ultimately be produced as blocks and stored.

At a step 1008, the off-chain software for witnesses (R) signs and sends transaction verification results to the blockchain network (S).

At a step 1009, the transaction verification results sent at step 1008 are collected by the blockchain network (S).

At a step 1010, the blockchain network (S) aggregates the received transaction verification results and may use a consensus model to reach an agreement on the final transaction verification results.

At a step 101 1 , after agreement is reached at step 1010, the blockchain network (S) then produces blocks for the verified transactions, and broadcasts and writes the aggregated transaction results i.e. the produced blocks to the blockchain network (S), and such blocks would be updated at the node (P).

As can be understood from Figures 9 and 10 and the accompanying description, a difference between an on-chain solution and an off-chain solution is in terms of where the transaction verification processes take place. The transaction verification processes of the on-chain solution are performed at a protocol-level (steps 908 to 91 0 of Figure 9). To be performed at protocol-level means that the transaction verification processes are programmed to be part of a protocol governing the operation/function of the software downloaded by each node to enable it to become a node of the blockchain-based network. No third party software is necessary to enable the transaction verification processes. In contrast, the transaction collection, broadcasting and transaction verification processes of the off-chain solution are performed at application-level (steps 1002 to 1008 of Figure 10), which requires third party software.

An on-chain solution can offer the following benefits:

1 . The on-chain solution has better overall response time and efficiency as the processes are performed at the protocol-level.

2. In an on-chain solution, there is no need for extra software to be installed in order to verify new transaction types that are added to the blockchain-based network after obtaining a consensus from the blockchain-based network to add the new transaction types.

3. The transaction verification process is integrated with a main blockchain-based network, thereby, the transaction verification process does not require extra steps to aggregate and store transaction verification results to a main-chain ledger, which is required in the case of an off-chain solution. This results in faster transaction verification process.

4. The on-chain solution is a better choice in terms of usability as users can transact using one type of coin when using the blockchain-based network. On the contrary, to deploy an off-chain solution, it is essential to have two kinds of coins, which includes a native coin of an underlying Blockchain-based network wherein the off-chain platform is deployed, and the coin of the off-chain platform.

5. The on-chain solution also do away with the need for steps taken to delegate work to an off-chain software and the security measures that accompanies such delegation and the need for interfacing the off-chain software with the main blockchain network. 6. As a private key of a node generating a transaction to be verified has to be shared with a third party software, there is a security issue if the third party software is not sufficiently protected against hacking. However, there is no such security issue in the on-chain solution. An off-chain solution is less secure than the on-chain solution.

7. The content distributed in the on-chain solution, such as video file, audio file, or any other file, can remain in the proposed blockchain-based network even during the Proofing or transaction validation stage and is not passed on to a third party software or source for validation. The stakeholders in the blockchain network of an off-chain solution have little or no control over third party softwares.

In the present disclosure, 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 1 100 described with reference to Figure 1 1 as follows.

Figure 1 1 shows in detail an example of a processor 1 100 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 1 100 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 1 100 may be deployed for the same purpose.

More specifically, in the example of Figure 1 1 , the programs and software described in the examples of the apparatus and method for video content validation in the present disclosure are executed by the processor 1 100. The processor 1 1 00 may comprise a processing unit 1 102 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.

Furthermore, the processing unit 1 102 may include user input modules such as a computer mouse 1 136, keyboard/keypad 1 104, and/or a plurality of output devices such as a display device 1 108. The display of the display device 1 108 may be a touch screen capable of receiving user input as well.

The processing unit 1 102 may be connected to a computer network 1 1 12 via a suitable transceiver device 1 1 14 (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 1 102 may also be connected to one or more external wireless communication enabled devices 1 134 via a suitable wireless transceiver device 1 132 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. Through the computer network 1 1 12, the processing unit 1 102 can gain access to one or more storages i.e. data storages, databases, data servers and the like connectable to the computer network 1 1 12 to retrieve and/or store data in the one or more storages.

The processing unit 1 1 02 may include an arithmetic logic unit (ALU) 1 1 1 8, a Random Access Memory (RAM) 1 120 and a Read Only Memory (ROM) 1 122. The processing unit 1 102 may also include a number of Input/Output (I/O) interfaces, for example I/O interface 1 138 to the computer mouse 1 136, a memory card and/or a Subscriber Identity Module (SIM) card slot or slots 1 1 16, I/O interface 1 124 to the display device 1 108, , and I/O interface 1 126 to the keyboard/keypad 1 104.

The components of the processing unit 1 102 typically communicate via an interconnected bus 1 128 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 1 100, or the processor (not shown) of one of the one or more external wireless communication enabled devices 1 134, 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 1 130. Such computer or application programs may also be downloaded from the computer network 1 1 12. The application programs are read and controlled in its execution by the processor 1 1 18. Intermediate storage of program data may be accomplished using RAM 1 120. In more detail, 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. The computer program when loaded and executed on such a general-purpose computer effectively results in an apparatus that implements the steps of the computing methods in examples herein described.

Examples of the present disclosure may have the following features.

A method for transaction verification in a blockchain-based network (e.g. 200 of Figure 2 and 810 of Figure 8), the method comprising: enabling a transaction of a plurality of transactions between a plurality of nodes in the blockchain-based network to be verified, wherein each node is a user device, wherein a verification node (e.g. W1 to W3 of Figure 7 and 806 of Figure 8) in the blockchain- based network is configured to verify correctness in performance of each transaction and to determine a verification result for each transaction; and receiving one or more block produced after aggregation of the verification result of one or more transactions verified to be correct, wherein a consensus model is provided on-chain in the blockchain-based network and is applied to reach an agreement on the verification result of a transaction being verified on the correctness in the performance of the transaction by different verification nodes, wherein each transaction to be verified is subjected to on-chain verification in the blockchain-based network based on one of a plurality of proofing techniques provided on-chain for transaction verification.

The plurality of transactions may comprise a first type of transaction in which one node transcodes a file on request of another node from one file format to another file format.

The plurality of transactions may comprise a second type of transaction in which one node stores a file on request of another node.

The plurality of transactions may comprise a third type of transaction in which a file is delivered from one node to another node.

The plurality of proofing techniques may comprise the proofing technique for the first type of transaction, the proofing technique for the second type of transaction and the proofing technique for the third type of transaction.

The consensus model may be based on Delegated Proof of Stake or Delegated Byzantine Fault Tolerance.

The method may comprise segmenting a file to be distributed in the blockchain-based network into more than one file segments; and initiating distribution of the more than one file segments in the blockchain-based network.

The method may comprise initiating replication of each of the more than one file segments; and requesting storage of a copy of each file segment in more than one node in the blockchain-based network.

The method may comprise initiating delivery of the more than one file segments of the file from more than one nodes storing the more than one file segments of the file to a node requesting for the file.

The delivery may be performed according to geographical proximity between the node making the request and the more than one nodes storing the file segments.

Verification of correctness of performance of a transaction of a type in which a node transcodes an original video on request of another node from one video format to another video format may be performed by: inputting the original video and the transcoded video for comparison; extracting a video frame descriptor from each frame of the original video and the transcoded video, wherein the video frame descriptors to be extracted are predetermined; processing the extracted video frame descriptors from each frame of the original video and the transcoded video to generate input to a mode! derived from a trained computer neura! network; outputting from the mode!, a distance vector to be used for calculation of a similarity value indicative of similarity between the original video and the transcoded video; and determining from the similarity value whether the performance of the transaction is correct.

Correctness of performance of a transaction of the plurality of transactions may be verified when a merkle tree (e.g. Figure 12) constructed for a file provided by one node to one verification node matches a merkle tree constructed for another file provided by another node to the verification node.

Correctness of performance of a transaction of the plurality of transactions may be verified when a merkle tree constructed from arbitrarily selected parts (e.g. arbitrarily selected frames of a video) of a file provided by one node to one verification node matches a merkle tree constructed for the same arbitrarily selected parts of another file provided by another node to the verification node.

Correctness of performance of a transaction of the plurality of transactions may be verified when an answer of a puzzle provided by one node to one verification node matches an answer of a puzzle provided by another node to the verification node.

The method may comprise providing periodically a time interval for transaction verification, wherein the following is performed during the transaction verification: broadcasting of the plurality of transactions; generation of a plurality of shards (e.g. S1 , S2 and S3 of Figure 6 and shard 1 and shard 2 of Figure 7) from the broadcasted transactions, wherein 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 to verify one or more transaction in each shard, wherein the one or more block is produced for the one or more transaction in each shard that is verified to be correctly performed.

Verification of correctness of performance of a transaction of a type in which a node transcodes original audio content on request of another node from one audio format to another audio format is performed by: inputting the original audio content and the transcoded audio content for comparison; obtaining a Chromaprint audio image for each of the original audio content and the transcoded audio content; filtering each Chromaprint audio image to obtain an audio fingerprint; and comparing the audio fingerprints of the original audio content and the transcoded audio content to determine similarity between the original audio content and the transcoded audio content.

An apparatus for transaction verification in a blockchain-based network (e.g. 200 of Figure 2 and 810 of Figure 8), the apparatus comprising: a memory; a processor configured to execute instructions in the memory to operate the apparatus to: enable a transaction of a plurality of transactions between a plurality of nodes in the blockchain-based network to be verified, wherein each node is a user device, wherein a verification node (e.g. W1 to W3 of Figure 7 and 806 of Figure 8) in the blockchain-based network is configured to verify correctness in performance of each transaction and to determine a verification result for each transaction; and receive one or more block produced after aggregation of the verification result of one or more transactions verified to be correct, wherein a consensus model is provided on-chain in the blockchain-based network and is applied to reach an agreement on the verification result of a transaction being verified on the correctness in the performance of the transaction by different verification nodes, wherein each transaction to be verified is subjected to on-chain verification in the blockchain-based network based on one of a plurality of proofing techniques provided on-chain for transaction verification.

The apparatus may be operable by the processor to: segment a file to be distributed in the blockchain-based network into more than one file segments; and initiate distribution of the more than one file segments in the blockchain-based network.

The apparatus may be operable by the processor to: initiate replication of each of the more than one file segments; and request storage of a copy of each file segment in more than one nodes in the blockchain-based network.

The apparatus may be operable by the processor to: initiate delivery of the more than one file segments of the file from more than one nodes storing the more than one file segments of the file to a node requesting for the file.

To verify correctness of performance of a transaction of a type in which a node transcodes an original video on request of another node from one video format to another video format, one of the plurality of verification nodes may be configured to: input the original video and the transcoded video for comparison; extract a video frame descriptor from each frame of the original video and the transcoded video, wherein the video frame descriptors to be extracted are predetermined; process the extracted video frame descriptors from each frame of the original video and the transcoded video to generate input to a mode! derived from a trained computer neural network; output from the model, a distance vector to be used for calculation of a similarity value indicative of similarity between the original video and the transcoded video; and determine from the similarity value whether the performance of the transaction is correct.

Correctness of performance of a transaction of the plurality of transactions may be verified when a merkle tree constructed for a file provided by one node to one verification node matches a merkle tree constructed for another file provided by another node to the verification node.

Correctness of performance of a transaction of the plurality of transactions may be verified when a merkle tree (e.g. Figure 12) constructed from arbitrarily selected parts (e.g. arbitrarily selected frames of a video) of a file provided by one node to one verification node matches a merkle tree constructed for the same arbitrarily selected parts of another file provided by another node to the verification node.

The apparatus may be operable by the processor to: provide periodically a time interval for transaction verification, wherein the plurality of transactions is broadcasted, a plurality of shards (e.g. S1 , S2 and S3 of Figure 6 and shard 1 and shard 2 of Figure 7) is generated from the broadcasted transactions and 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 are assigned to verify one or more transaction in each shard, wherein the one or more block is produced for the one or more transaction in each shard that is verified to be correctly performed.

To verify correctness of performance of a transaction of a type in which a node transcodes an original video on request of another node from one video format to another video format, one of the plurality of verification nodes is configured to: input the original audio content and the transcoded audio content for comparison; obtain a Chromaprint audio image for each of the original audio content and the transcoded audio content; filter each Chromaprint audio image to obtain an audio fingerprint; and comparing the audio fingerprints of the original audio content and the transcoded audio content to determine simiiarity between the origina! audio content and the transcoded audio content.

Throughout this specification and claims which follow, unless the context requires otherwise, the word“comprise”, and variations such as“comprises” or“comprising”, will be understood to imply the inclusion of a stated integer or group of integers or steps but not the exclusion of any other integer or group of integers.

While the invention has been described in the present disclosure in connection with a number of embodiments and implementations, the invention is not so limited but covers various obvious modifications and equivalent arrangements, which fall within the purview of the appended claims. Although features of the invention are expressed in certain combinations among the claims, it is contemplated that these features can be arranged in any combination and order.

Claims

1 . A method for transaction verification in a blockchain-based network, the method comprising: enabling a transaction of a plurality of transactions between a plurality of nodes in the blockchain-based network to be verified, wherein each node is a user device, wherein a verification node in the blockchain-based network is configured to verify correctness in performance of each transaction and to determine a verification result for each transaction; and

receiving one or more block produced after aggregation of the verification result of one or more transactions verified to be correct,

wherein a consensus model is provided on-chain in the blockchain-based network and is applied to reach an agreement on the verification result of a transaction being verified on the correctness in the performance of the transaction by different verification nodes, wherein each transaction to be verified is subjected to on-chain verification in the blockchain-based network based on one of a plurality of proofing techniques provided on-chain for transaction verification.

2. The method as claimed in claim 1 , wherein the plurality of transactions comprises a first type of transaction in which one node transcodes a file on request of another node from one file format to another file format.

3. The method as claimed in claim 1 or 2, wherein the plurality of transactions comprises a second type of transaction in which one node stores a file on request of another node.

4. The method as claimed in claim 1 , 2 or 3, wherein the plurality of transactions comprises a third type of transaction in which a file is delivered from one node to another node.

5. The method as claimed in claim 4, wherein the plurality of proofing techniques comprises the proofing technique for the first type of transaction, the proofing technique for the second type of transaction and the proofing technique for the third type of transaction.

6. The method as claimed in any one of claims 1 to 5, wherein the consensus model is based on Delegated Proof of Stake or Delegated Byzantine Fault Tolerance.

7. The method as claimed in any one of claims 1 to 6, wherein the method comprises:

segmenting a file to be distributed in the blockchain-based network into more than one file segments; and

initiating distribution of the more than one file segments in the blockchain-based network.

8. The method as claimed in claim 7, wherein the method comprises:

initiating replication of each of the more than one file segments; and

requesting storage of a copy of each file segment in more than one node in the blockchain- based network.

9. The method as claimed in claim 7 or 8, wherein the method comprises:

initiating delivery of the more than one file segments of the file from more than one nodes storing the more than one file segments of the file to a node requesting for the file.

10. The method as claimed in claim 9, wherein the delivery is performed according to geographical proximity between the node making the request and the more than one nodes storing the file segments.

1 1 . The method as claimed in any one of claims 1 to 10, wherein verification of correctness of performance of a transaction of a type in which a node transcodes an original video on request of another node from one video format to another video format is performed by:

inputting the original video and the transcoded video for comparison; extracting a video frame descriptor from each frame of the original video and the transcoded video, wherein the video frame descriptors to be extracted are predetermined; processing the extracted video frame descriptors from each frame of the original video and the transcoded video to generate input to a model derived from a trained computer neural network; outputting from the model, a distance vector to be used for calculation of a similarity value indicative of similarity between the original video and the transcoded video; and

determining from the similarity value whether the performance of the transaction is correct.

12. The method as claimed in any one of claims 1 to 1 1 , wherein correctness of performance of a transaction of the plurality of transactions is verified when a merkle tree constructed for a file provided by one node to one verification node matches a merkle tree constructed for another file provided by another node to the verification node.

13. The method as claimed in any one of claims 1 to 12, wherein correctness of performance of a transaction of the plurality of transactions is verified when a merkle tree constructed from arbitrarily selected parts of a file provided by one node to one verification node matches a merkle tree constructed for the same arbitrarily selected parts of another file provided by another node to the verification node.

14. The method as claimed in any one of claims 1 to 13, wherein correctness of performance of a transaction of the plurality of transactions is verified when an answer of a puzzle provided by one node to one verification node matches an answer of a puzzle provided by another node to the verification node.

15. The method as claimed in any one of claims 1 to 14, wherein the method comprises:

providing periodically a time interval for transaction verification, wherein the following is performed for the transaction verification:

broadcasting of the plurality of transactions;

generation of a plurality of shards from the broadcasted transactions, wherein 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 to verify one or more transaction in each shard,

wherein the one or more block is produced for the one or more transaction in each shard that is verified to be correctly performed.

16. The method as claimed in any one of claims 1 to 15, wherein verification of correctness of performance of a transaction of a type in which a node transcodes original audio content on request of another node from one audio format to another audio format is performed by:

inputting the original audio content and the transcoded audio content for comparison;

obtaining a Chromaprint audio image for each of the original audio content and the transcoded audio content;

filtering each Chromaprint audio image to obtain an audio fingerprint; and

comparing the audio fingerprints of the original audio content and the transcoded audio content to determine similarity between the original audio content and the transcoded audio content.

17. An apparatus for transaction verification in a blockchain-based network, the apparatus comprising:

a memory;

a processor configured to execute instructions in the memory to operate the apparatus to: enable a transaction of a plurality of transactions between a plurality of nodes in the blockchain-based network to be verified, wherein each node is a user device, wherein a verification node in the blockchain-based network is configured to verify correctness in performance of each transaction and to determine a verification result for each transaction; and

receive one or more block produced after aggregation of the verification result of one or more transactions verified to be correct, wherein a consensus model is provided on-chain in the blockchain- based network and is applied to reach an agreement on the verification result of a transaction being verified on the correctness in the performance of the transaction by different verification nodes, wherein each transaction to be verified is subjected to on-chain verification in the blockchain-based network based on one of a plurality of proofing techniques provided on-chain for transaction verification.

18. The apparatus as claimed in claim 17, wherein the plurality of transactions comprises a first type of transaction in which one node transcodes a file on request of another node from one file format to another file format.

19. The apparatus as claimed in claim 17 or 18, wherein the plurality of transactions comprises a second type of transaction in which one node stores a file on request of another node.

20. The apparatus as claimed in claim 17, 18 or 19, wherein the plurality of transactions comprises a third type of transaction in which a file is delivered from one node to another node.

21 . The apparatus as claimed in claim 20, wherein the plurality of proofing techniques comprises the proofing technique for the first type of transaction, the proofing technique for the second type of transaction and the proofing technique for the third type of transaction.

22. The apparatus as claimed in any one of claims 17 to 21 , wherein the consensus model is based on Delegated Proof of Stake or Delegated Byzantine Fault Tolerance.

23. The apparatus as claimed in any one of claims 17 to 22, wherein the apparatus is operable by the processor to:

segment a file to be distributed in the blockchain-based network into more than one file segments; and

initiate distribution of the more than one file segments in the blockchain-based network.

24. The apparatus as claimed in claim 23, wherein the apparatus is operable by the processor to: initiate replication of each of the more than one file segments; and

request storage of a copy of each file segment in more than one nodes in the blockchain- based network.

25. The apparatus as claimed in claim 23 or 24, wherein the apparatus is operable by the processor to:

initiate delivery of the more than one file segments of the file from more than one nodes storing the more than one file segments of the file to a node requesting for the file.

26. The apparatus as claimed in claim 25, wherein the delivery is performed according to geographical proximity between the node making the request and the more than one nodes storing the file segments.

27. The apparatus as claimed in any one of claims 17 to 26, wherein to verify correctness of performance of a transaction of a type in which a node transcodes an original video on request of another node from one video format to another video format, one of the plurality of verification nodes is configured to:

input the original video and the transcoded video for comparison;

extract a video frame descriptor from each frame of the original video and the transcoded video, wherein the video frame descriptors to be extracted are predetermined; process the extracted video frame descriptors from each frame of the original video and the transcoded video to generate input to a model derived from a trained computer neural network;

output from the model, a distance vector to be used for calculation of a similarity value indicative of similarity between the original video and the transcoded video; and

determine from the similarity value whether the performance of the transaction is correct.

28. The apparatus as claimed in any one of claims 17 to 27, wherein correctness of performance of a transaction of the plurality of transactions is verified when a merkle tree constructed for a file provided by one node to one verification node matches a merkle tree constructed for another file provided by another node to the verification node.

29. The apparatus as claimed in any one of claims 17 to 28, wherein correctness of performance of a transaction of the plurality of transactions is verified when a merkle tree constructed from arbitrarily selected parts of a file provided by one node to one verification node matches a merkle tree constructed for the same arbitrarily selected parts of another file provided by another node to the verification node.

30. The apparatus as claimed in any one of claims 17 to 29, wherein correctness of performance of a transaction of the plurality of transactions is verified when an answer of a puzzle provided by one node to one verification node matches an answer of a puzzle provided by another node to the verification node.

31 . The apparatus as claimed in any one of claims 17 to 30, wherein the apparatus is operable by the processor to:

provide periodically a time interval for transaction verification,

wherein the transaction verification, the plurality of transactions is broadcasted, a plurality of shards is generated from the broadcasted transactions and 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 are assigned to verify one or more transaction in each shard,

32. The apparatus as claimed in any one of claims 17 to 31 , wherein to verify correctness of performance of a transaction of a type in which a node transcodes an original video on request of another node from one video format to another video format, one of the plurality of verification nodes is configured to:

input the origina! audio content and the transcoded audio content for comparison;

obtain a Chromaprint audio image for each of the original audio content and the transcoded audio content;

filter each Chromaprint audio image to obtain an audio fingerprint; and

comparing the audio fingerprints of the origina! audio content and the transcoded audio content to determine similarity between the original audio content and the transcoded audio content.