Patent Description:
Decentralised ledger technology has attracted much interest in recent years due to its flexibility of applications: from providing an architecture for utility tokens that can be used to deploy built-in smart contracts.

However, block chain backed transactions suffer from several limitations. Due to the nature in which transactions are validated, which requires multiple machine consensus, this leads to latency when numerous transactions are simultaneously processed. Latency causes difficulties when scaling block chain technology to support internet of things (IoT) applications, whereby the loT market is expecting exponential growth from $157b to $457b from <NUM> to <NUM>, according to a December <NUM>, <NUM> article published by Forbes<NUM>. The very nature of block chain technology, being a decentralised ledger, has a security flaw known as a "<NUM>% attack", whereby if more than half of the machines validate a ledger containing erroneous records, it is possible for dishonest transactions to be erroneously processed as valid transactions. Privacy is also a concern, since past transactions can be obtained from which identities can be obtained.

While there are existing approaches that try to improve latency and improve security of block chain technology, many of these approaches address these drawbacks unilaterally, without fully capitalising on the capability of block chain technology.

The present invention seeks to addresses the above shortcomings and delivers a system that harnesses block chain technology more effectively.

<CIT> describes that a first processor-accessible memory device system and a second processor-accessible memory device system of a self-regulating transaction system may each store a respective local copy of one or more transaction ledgers that record transactions. A first data processing device system may be configured to generate a transaction information block associated with a particular market channel, store it in the local copy of a transaction ledger associated with the particular market channel stored in the first processor-accessible memory device system, and transmit it to a second data processing device system over a communications network for storage in the local copy of the transaction ledger associated with the particular market channel stored in the second processor-accessible memory device system.

<CIT> describes a digital ledger built upon a blockchain to provide users with the ability to securely, accurately, and verifiably share state information between distrustful parties. The Verifiable Outsourced Ledger is hosted in a networked environment, accessible by multiple parties, and maintains an immutable view of the transactions submitted by authorized parties and a continuous view of the states shared between the parties that the parties can replicate independently locally to verify the integrity of the ledger.

<CIT> describes a data protection system and method are disclosed. The data protection system includes a data repository, a data access interface and an authentication system. The data repository stores user data for a user. The user data comprises a plurality of individually encrypted components. The data access interface is arranged to provide remote access to each of the individually encrypted components in encrypted form. The data protection system is arranged to provide selective access to each individual component in unencrypted form upon the authentication system authenticating the user for the respective component.

<CIT> describes an Internet of Thing (IoT) device that includes a camera coupled to a processor; and a wireless transceiver coupled to the processor. Blockchain smart contracts can be used with the device to facilitate secure operation.

According to one aspect of the invention, there is provided a multi-access edge computing node located to utilise radio access network infrastructure of a base station of a mobile network operator for cellular communication that comprises <NUM> and <NUM> frequency bands, the multi-access edge computing node comprising at least one memory to store a chained data block, where each data block is coded with data of a past transaction in respect of a good or service; and at least one processor configured with functions that: include a new data block, to record a current transaction in respect of a good or service, into the chained data block in response to a signature, generated from processing the data of the current transaction with the coded data of the past transactions stored in the chained data block, being validated by other multi-access edge computing nodes, wherein the multi-access edge computing node and the other multi-access edge computing nodes are trusted, and communicate over a common channel, wherein data in respect of transactions is received through cellular connection provided by the base station.

Optional features are specified in the dependent claims.

Representative embodiments of the present invention are herein described, by way of example only, with reference to the accompanying drawings, wherein:.

In the following description, various embodiments are described with reference to the drawings, where like reference characters generally refer to the same parts throughout the different views.

The present application, in a broad overview, relates to a ledger that is distributed across a system of multi-access edge computing nodes. The ledger is a database storing records of entries of monitored transactions, distributed by each of the multi-access edge computing nodes hosting a replicate. In the context of IoT applications, a transaction may be automatically initiated by IoT devices themselves (i.e. machine to machine or M2M), provided certain conditions are met; or may require human intervention, such as an operator working an IoT device at one end (machine to human or M2H) or an operator working an loT device at each end (human to human.

The distributed ledger is also synchronised in that when one of the hosted ledgers is updated to record data of a new transaction into past transaction data, its hosting multi-access edge computing node checks whether the updated ledger is in consensus with ledgers hosted in other multi-access edge computing nodes, updated with data of the same new transaction. Machine to machine validation is achieved when at least a majority of the other multi-access edge computing nodes are in agreement with the updated ledger. In one implementation, delegated proof of stake (DPoS) consensus is used, where agreement is sought from a percentage (e.g. <NUM>%) of a selected group of multi-access edge computing nodes (called "witnesses"). The selected group of multi-access edge computing nodes are those that produce trusted results, i.e. multi-access edge computing nodes that produce updated ledgers that are in conformance when each of them record a new data block containing data of the new transaction. The group of multi-access edge computing nodes from which agreement is sought is voted by stakeholder multi-access edge computing nodes. These stakeholders are multi-access edge computing nodes possessing utility tokens providing a percentage ownership of the platform created by the system of multi-access edge computing nodes to host the distributed ledger. Since only trusted multi-access edge computing nodes validate an updated ledger, this reduces the probability of a "<NUM>% attack" from having the multi-access edge computing nodes adopt known "proof of work" techniques. Having only a selected number of multi-access edge computing nodes validate the updated ledger also reduces latency, compared to the "proof of work" approach. In one implementation, only <NUM>% of an elected group of multi-access edge computing nodes perform the ledger update.

Each multi-access edge computing node is located within a cellular coverage area supported by a base station of a mobile network operator, such as being adjacent to the base station. The multi-access edge computing node operates under <NUM> and <NUM> frequency bands, in accordance with technical standards as defined by the European Telecommunications Standards Institute (ETSI) and 3GPP (<NUM>rd Generation Partnership Project) in respect of multi-access edge computing. Accordingly, the multi-access edge computing node is placed in proximity to the base station. to utilise the radio access network infrastructure of the base station that provides for cellular communication in these <NUM> and <NUM> frequency bands, so that the multi-access edge computing node operates under broadcast network conditions, rather than private network conditions. An example operating spectrum lies within <NUM> to <NUM>, to harness lower latency and higher throughput as compared to operating in this spectrum.

Collectively, the multi-access edge computing nodes provide for multi-access edge computing, a network architecture that supports greater computing and storage capacity at a network edge compared to those available to interconnected computer systems within the network, such as a central data centre or cloud location. Traditional distributed ledgers hosted on such network resources experience latency before transactions can reach these distributed ledgers to be processed and therefore processes which seek to rely on platforms that run such distributed ledgers cannot be effectively scaled. Conversely, having a distributed ledger hosted at the network edge harnesses the lower latency and better performance capabilities offered by multi-access edge computing for allowing task processing closer to end user devices. As such, multi-access edge nodes and their hosted distributed ledger, implemented in accordance with the present invention, provides a platform that facilities transactions to be performed on Internet of things (IoT) devices, i.e. any device which is embedded with electronics that enables the device to collect and exchange data that is in respect of the transaction, as long as the device can communicate with any of the multi-access edge computing nodes, e.g. through the cellular connection provided by the base station that supports the multi-access edge computing node.

The mobile network operator refers to any telecommunication company owning the rights to broadcast within an allocated frequency spectrum, with the base station providing the infrastructure to create a cell in a cellular network. Accordingly, the base station allows the mobile network operator to have wireless data communication over the allocated frequency spectrum and also a gateway to the core network serviced by the base station, the core network being part of interconnected computer systems, such as the Internet,.

In addition to operating a protocol stipulating how consensus is achieved in their distributed ledger, each of the multi-access edge computing nodes also operates a protocol that has each of the multi-access edge computing nodes communicate over a common channel, like a communication path that is used for one base station to communicate with another base station. This restricts commimication over direct communication paths that are used between base stations and reduces latency, as opposed to routing communication through the core network. This is in contrast to distributed ledgers that run on radio access networks.

The following disclosure provides implementation details of the multi-access edge computing node that facilitates the distributed ledger capability hosted by the multi-access edge computing node. Broadly, the multi-access edge computing node has a stock processor (being a standard server processor), along with a dedicated processor (being a specifically designed processor separate from the stock processor), responsible for updating the distributed ledger when a new data block is to be included. A policy engine is responsible for deciding an algorithm for use to validate transactions recorded into the distributed ledger and processing output of zero knowledge protocols which are used when transactions containing shielded data are to be recorded into the distributed ledger. This policy engine may also be further configured to determine whether computations that are undertaken to validate an update to the distributed ledger are undertaken by the stock processor or the dedicated processor.

<FIG> is a schematic of a portion of a system <NUM> comprising base stations <NUM>, <NUM> and <NUM>, each supporting a respective multi-access edge computing node <NUM>, <NUM> and <NUM>. so that each of the multi-access edge computing nodes <NUM>, <NUM> and <NUM> can tap into the data transmission and receipt capability of the cellular coverage that their respective base stations <NUM>, <NUM> and <NUM> provide. In one implementation, this is achieved by locating each of the multi-access edge computing node <NUM>, <NUM> and <NUM> within the cellular coverage area of its respective base station <NUM>, <NUM> and <NUM>. In another implementation, this is achieved by locating the multi-access edge computing node <NUM>, <NUM> and <NUM> at or next to its respective base station <NUM>, <NUM> and <NUM>. For the sake of simplicity, all other multi-access edge computing nodes and their respective associated base station are not shown in the schematic for system <NUM>.

In one implementation, each of the base stations <NUM>, <NUM> and <NUM> belongs to the same mobile network operator. Communication between each of the multi-access edge computing nodes <NUM>, <NUM> and <NUM> to process a transaction is initiated by subscribers to this mobile network operator. In another implementation, each of the base stations <NUM>, <NUM> and <NUM> belongs to a different mobile network operator. Communication between each of the multi-access edge computing nodes <NUM>, <NUM> and <NUM> to process a transaction is in accordance with conditions of an operator roaming partnership between the different mobile network operators, where the transaction is initiated by subscribers to each of the respective mobile network operators.

In yet another implementation the base stations <NUM>, <NUM> and <NUM> belong to a third party, whereby each of them is used by different mobile network operators to facilitate communication between each of the multi-access edge computing nodes <NUM>, <NUM> and <NUM> to process a transaction initiated by parties that subscribe to different mobile network operators. For instance, base station <NUM> may be used by mobile network operators A, B and C, so that the multi-access edge computing node <NUM> will first receive notification if a transaction is initiated by a subscriber of either mobile network operator A, B and C while in the cellular coverage area of base station <NUM>.

Communication between the multi-access edge computing node <NUM> to the other multi-access edge computing nodes <NUM> and <NUM> to validate a transaction (e.g. occurring at an electric vehicle (EV) charging station <NUM>, where the two transacting parties are a charging station operator and an EV operator) will occur over communication path <NUM>, <NUM> that the base stations <NUM>. <NUM> and <NUM> use to communicate data with each other, rather than being routed through a mobile network operator core network <NUM>. The establishment of a common channel along the communication path <NUM>, <NUM> to isolate communication between the multi-access edge computing nodes <NUM>, <NUM> and <NUM> serves to reduce latency time for processing of the transaction (e.g. between the charging station operator and the EV operator). Even in instances where validating, for example a cross border transaction, requires communication with the mobile network operator core network <NUM> to draw resources (such as to acquire a currency exchange rate for the cross border transaction, i.e. when utility tokens owned by a transacting party at one end is in a jurisdiction different from a jurisdiction in which a transacting party of the other end is located), the common channel along the communication path <NUM>, <NUM> is still utilised by the multi-access edge computing nodes <NUM> and <NUM> to validate the cross border transaction. The communication path <NUM>. <NUM> may be realised using wired or wireless means.

Each of the multi-access edge computing nodes <NUM>, <NUM> and <NUM> has at least one memory to store a chained data block. A chained data block is essentially a record of a transfer of ownership during transactions from the first to the most recent, so that the chained data block provides a ledger function that is shared by the multi-access edge computing nodes <NUM>, <NUM> and <NUM>. Its data structure is a hash pointer to back-linked blocks of transactions. Each block is identifiable by a hash. generated for example using the SHA256 cryptographic hash algorithm, on the header of the block. The header of each block references a previous block. Each block contains the hash of its parent inside its own header. There lays a chain going all the way back to the first block created, also known as the genesis block, linked together by a sequence of hashes.

Since the system <NUM> does not have a centralised body to authenticate any of its supportable transactions, but uses machine to machine validation, each of the multi-access edge computing nodes <NUM>, <NUM> and <NUM> relies on the ledger function of the chained data block to determine whether there is sufficient assets to execute a new transaction; the assets referring to, for example, whether there is stock for the good or funds in a digital wallet to pay for the good.

<FIG> shows a schematic of a protocol <NUM> used to construct a chained data block in each of the multi-access edge computing nodes <NUM>, <NUM> and <NUM>, the construction being based on a delegated proof of stake principle as explained in greater detail below. To simplify the explanation of the construction of the chained block of data. <FIG> assumes that each of the multi-access edge computing nodes <NUM>, <NUM> and <NUM> is trusted, i.e. they are amongst the witnesses of all multi-access edge computing nodes (i.e. including those that are not shown in <FIG>) through majority vote. These witness multi-access edge computing nodes are responsible for ensuring the integrity of the shared ledger, i.e. they validate a transaction for recording into the shared ledger. Agreement is not required from all of the witness multi-access edge computing nodes, but only a majority of them (e.g. <NUM>%, although any other pre-defined percentage may be set) to validate the transaction. In one implementation, the number of utility tokens that are distributed nodes is finite and owned by stakeholders, where the stakeholders will continuously monitor for the best performing multi-access edge computing nodes and vote them to be trusted to be the witness multi-access edge computing nodes. In one implementation, there are <NUM> multi-access edge computing nodes acting as witnesses, to which consensus has to be reached by <NUM> or <NUM> of them. However, in another implementation, a different number of multi-access edge computing nodes (i.e. not necessarily <NUM>) act as witnesses, while another percentage (i.e. not necessarily <NUM>%) of the witness multi-access edge computing nodes is required to reach consensus. The number of witness multi-access edge computing nodes <NUM> and <NUM> and their percentage to reach consensus is in accordance with network settings, which may be determined by parties called "delegates", which is described later in more detail in <FIG>. Ensuring that ledger consensus exists within a predetermined percentage of all the multi-access edge computing nodes reduces the processing time taken to arrive at such consensus.

During initialisation, the shared ledger has no content, so that information of a first transaction. "block0data", becomes content of a first data block <NUM> (the genesis block) for inclusion into the shared ledger of any of the multi-access edge computing node <NUM>, <NUM> and <NUM>. The information provided by "block0data" depends on the nature of the transaction that is being recorded. For instance if the transaction relates to the purchase of a good or service, the information may include one or more of pointers that can give detail on: the type of good or service, its cost: details of a digital wallet used to fund it and the balance of the digital wallet thereafter: an inventory from which the good is to be drawn: and an identity of the parties to the transaction (such as seller and purchaser, and the shipper from the seller to the purchaser). If the transaction relates to supply chain management, the information may include one or more of pointers that can give detail on: the type of good or service being monitored, their respective cost price and selling price; an inventory of a warehouse from which a good is stocked: an inventory of a location to which the good is delivered; an identity of the warehouse where the good is stocked; an identity of the location to which the good is delivered; an identity of the party delivering the good; and an identity of the supplier of the good or service. Such information exists as data (i.e. a string of computer bits). A combination of "block0data". a hash value of a previous data block and a random nonce becomes input to a hash function. Since there are no previous data blocks, the previous hash value is "<NUM>", so that the hash value of the first data block <NUM> is the hash value of "block0data". The hash function is such that for any input, its output is a string of random letters and numbers, where the same input would always give the same string of output, but any change in the input would cause the output to change randomly. The application here is to solve a math problem where the output is in a specific data format (such as starting with a predefined combination of characters, e.g. seven zeros or a mixture of letters and numbers), so that the random nonce is repeatedly changed to produce such an output. In the case of <FIG>, the hash value of the first data block <NUM> is "0xea34ad. <NUM>", which becomes the signature of the first data block <NUM>, with "$#<NUM>" being the random nonce found to produce this hash value. Assuming, for the sake of simplicity, that the transaction of "block0data" is the first of its kind, the hash value "0xea34ad. <NUM>" is time stamped, dated, serialised with an index value "<NUM>" to successful create the first data block <NUM>, for referencing back from later chained data blocks. The successful creation of the first data block <NUM> is broadcast over the communication path <NUM>, <NUM> that the base stations <NUM>, <NUM> and <NUM> use to communicate data with each other, for each of the multi-access edge computing nodes <NUM>, <NUM> and <NUM> to keep a copy of the first data block <NUM>.

Information of a second transaction, "blockldata" for inclusion as a second data block <NUM> into the shared ledger is as follows.

The content of "blockldata" varies depending on the nature of the second transaction, so that the above comments regarding "block0data" equally apply. A combination of "blockldata", the hash value of the first data block <NUM> (i.e. "0xea34ad. <NUM>") and a random nonce becomes input to a hash function. In the case of <FIG>, the hash value of the second data block <NUM> is "0xf6e1da2. deb", which becomes the signature of the second data block <NUM>, with "@$%" being the random nonce found to produce this hash value.

All the multi-access edge computing nodes <NUM>, <NUM> and <NUM> will receive a notification of the second transaction seeking to be recorded in the shared ledger, where each will then seek to solve to obtain a signature of the second data block <NUM>. Assuming that the multi-access edge computing node <NUM> is the first to obtain the signature of the second data block <NUM>, the multi-access edge computing node <NUM> broadcasts the signature of the second data block <NUM> to the multi-access edge computing node <NUM> and multi-access edge computing node <NUM>, which from the perspective of the multi-access edge computing node <NUM> are external multi-access edge computing nodes that are trusted. Each of the multi-access edge computing nodes <NUM> and <NUM> validates the signature of the second data block <NUM> by referencing the previous validated data block, namely the first data block <NUM> ("block0data"), through the hash value of the first data block. The hash of the first data block <NUM> and the random nonce are then hashed to determine whether an output is produced having the earlier described specific data format (i.e. starting with a predefined combination of characters, e.g. seven zeros or a mixture of letters and numbers). If so, the signature of the second data block <NUM> is validated, i.e. consensus is reached by the multi-access edge computing nodes <NUM> and <NUM>. With consensus determined, the hash value "0xf6elda2. deb" is time stamped, dated, serialised with an index value "<NUM>", resulting in the successful creation of the second data block <NUM>. Since the second transaction occurs after the first transaction, the second data block <NUM> has a later time stamp of "<NUM>:<NUM>" compared to the time stamp "<NUM>:<NUM>" of the first data block <NUM>. The successful creation of the second data block <NUM> is broadcast over the communication path <NUM>, <NUM> that the base stations <NUM>, <NUM> and <NUM> use to communicate data with each other, for each of the multi-access edge computing nodes <NUM>, <NUM> and <NUM> to keep a copy of the second data block <NUM>.

Information of a third transaction. "block2data", for inclusion as a third data block <NUM> into the shared ledger follows a similar procedure to that of inclusion of the second transaction, "blockldata" as the second data block <NUM> into the shared ledger.

The content of "block2data" varies depending on the nature of the third transaction, so that the above comments regarding "block0data" equally apply. A combination of "block2data", the hash value of the second data block <NUM> (i.e. "0xf6elda2. deb") and a random nonce becomes input to a hash function. In tire case of <FIG>, the hash value of the third data block <NUM> is "0x9327eb1b. 36a21", which becomes the signature of the third data block <NUM>, with "#!!" being the random nonce found to produce this hash value.

All the multi-access edge computing nodes <NUM>, <NUM> and <NUM> will receive a notification of the third transaction seeking to be recorded in the shared ledger, where each will then seek to solve to obtain a signature of the third data block <NUM>. Again assuming that the multi-access edge computing node <NUM> is the first to obtain the signature of the third data block <NUM>, the multi-access edge computing node <NUM> broadcasts the signature of the third data block <NUM> to the multi-access edge computing node <NUM> and multi-access edge computing node <NUM>. which from the perspective of the multi-access edge computing node <NUM> are external multi-access edge computing nodes that are trusted. Each of the multi-access edge computing nodes <NUM> and <NUM> validates the signature of the third data block <NUM> by referencing the previous validated data block, namely the second data block <NUM> ("blockldata"), through the hash value of the second data block. The hash of the second data block <NUM> and the random nonce are then hashed to determine whether an output is produced having the earlier described specific data format (i.e. starting with a predefined combination of characters, e.g. seven zeros or a mixture of letters and numbers). If so, the signature of the third data block <NUM> is validated, i.e. consensus is reached by the multi-access edge computing nodes <NUM> and <NUM>. With consensus determined, the hash value "0x9327eblb. 36a21" is time stamped, dated, serialised with an index value "<NUM>", resulting in the successful creation of the third data block <NUM>. Since the third transaction occurs after the second transaction, the third data block <NUM> has a later time stamp of "<NUM>:<NUM>" compared to the time stamp "<NUM>:<NUM>" of the second data block <NUM>. The successful creation of the third data block <NUM> is broadcast over the communication path <NUM>, <NUM> that the base stations <NUM>, <NUM> and <NUM> use to communicate data with each other, for each of the multi-access edge computing nodes <NUM>, <NUM> and <NUM> to keep a copy of the third data block <NUM>.

Returning to <FIG>, the system <NUM> is shown to support a use case of smart contracts <NUM>, <NUM> that relate to managing of power usage, which sees the provision of power from a power plant <NUM> to a drone charging station <NUM> and an electric vehicle (EV) charging station <NUM>. A smart contract refers to a digital contract, which is a contract whose terms and conditions are programmed into computer code, stored and replicated across a distributed ledger. Deployment of the smart contract into the distributed ledger is done by the power plant <NUM> communicating with the multi-access edge computing node <NUM>, for being closest. The smart contract <NUM> for drone charging and the smart contract <NUM> for EV charging may use different terms and conditions, which can be accommodated by the distributed ledger of the multi-access edge computing nodes <NUM>, <NUM> and <NUM>.

<FIG> shows that the EV charging station <NUM> is in proximity to the multi-access edge computing node <NUM>, so that should a transaction (such as charging of an electric vehicle) be initiated in accordance with smart contract <NUM>, access to having the transaction processed by the distributed ledger hosted by the system <NUM>. would be through the multi-access edge computing node <NUM>. Similarly, the drone charging station <NUM> is in proximity to the multi-access edge computing node <NUM>, so that should a transaction (such as charging of a drone) be initiated in accordance with smart contract <NUM>, access to having the transaction processed by the distributed ledger hosted by the system <NUM>. would be through the multi-access edge computing node <NUM>. With reference to <FIG>, the blockchain in the distributed ledger could be adapted to, for example, cater for consensus agreement as to whether a digital wallet has sufficient funds to pay for a requested amount of power. from analysing a new transaction against past transactions. It will be appreciated that while only an EV charging station <NUM> and a drone charging station <NUM> are shown, any other platforms that adopt the distributed ledger hosted by the system <NUM> can also utilise the distributed ledger by tapping into the most proximate multi-access edge computing node. Each of the multi-access edge computing nodes receive notifications of a transaction being sought to be recorded in the distributed ledger through the cellular connection provided by their associated base station.

In addition to managing power usage, other smart contracts supportable by the distributed ledger of the system <NUM> include purchase and sales contracts. crediting and debiting of a digital wallet, tracking of resources in a supply chain. the streaming of media content and the monitoring of road traffic conditions.

<FIG> shows a use case of smart contracts <NUM> and <NUM> that relate to supply chain management, these smart contracts <NUM> and <NUM> being written into the ledgers of the multi-access edge computing nodes <NUM>, <NUM> and <NUM>. Similar to <FIG>, each of the parties (namely a primary manufacturer <NUM>, a subcontracted manufacturer <NUM> and a logistics company <NUM> delivering the finished goods on behalf of the subcontracted manufacturer <NUM>) communicate status of a good to the closest multi-access edge computing node <NUM>, <NUM> and <NUM>. The smart contract <NUM> may assist with supply chain management as follows.

The primary manufacturer <NUM> subcontracts certain manufacturing parts to the subcontractor manufacturer <NUM>. They both initiate a smart contract <NUM> based on agreed terms and conditions. The subcontractor manufacturer <NUM> then deploys a smart contract <NUM> with the logistics company <NUM> in delivering the final product to the primary manufacturer <NUM>. All smart contracts <NUM> and <NUM> are logged on the distributed ledger from which the primary manufacturer <NUM> can track in real-time events prior to the arrival of the final good.

<FIG> shows a use case of a smart contract <NUM> that relate to streaming media from a source <NUM> to a recipient device (e.g. a monitor, speaker or both) provided inside a vehicle <NUM>. The base station <NUM> supporting the multi-access edge computing node <NUM> may be situated in a different region (e.g. the US) from that of the base station <NUM> supporting the multi-access edge computing node <NUM> (e.g. in Asia), so that a US based mobile network operator uses the base station <NUM>. while an Asian based mobile network operator uses the base station <NUM>. The smart contract <NUM> is coded to account for regulation requirements in the different region in which each party resides (the source <NUM> being in Asia and the vehicle <NUM> being in the US), with digital wallets <NUM> and <NUM> being used to secure payment for the media being streamed from the source <NUM> to the recipient device inside the vehicle <NUM>. Similar to <FIG>, the distributed ledger hosted by the multi-access edge computing nodes <NUM> and <NUM> is adapted to cater for consensus agreement with regard to the status of each of the digital wallets <NUM> and <NUM> when processing the media stream, from analysing a new transaction against past transactions.

Network slicing <NUM> is deployed by mobile network operators network function virtualisation (NFV) core network. The source <NUM> and the monitor in the vehicle <NUM> become parties to the virtual network, where the virtual network allows the correct level of connectivity allowing the source <NUM> to communicate with the recipient device inside the vehicle <NUM>. This is particularly advantageous since IoT may be customisable elements (e.g. a simple circuit board with the necessary electronics to perform their specific purpose), rather than a full-fledged computing terminal. Since such elements may run their own architecture, the need for them to communicate with high data rate, low latency and good QoS (Quality of Service) becomes important, which is facilitated by them being part of the virtual network. The distributed ledger then provides the backbone architecture to ensure that transactions in accordance with smart contracts that each of these elements are designed to support can be validated.

The use case of <FIG> applies in a scenario of federated network slicing utilising <NUM> technology that offers cross border intercontinental services as follows. Assume an autonomous taxi company (based in the US) has signed up with a multimedia advertising company (based in Asia) for providing advertising services within the in-car system. Both companies are located in different continents. There is an open slot for a five minutes advertising campaign. The multimedia advertising company will initiate a smart contract through the multi-access edge computing nodes <NUM> with the taxi company (confer reference numeral <NUM>), once the payment is validated on the distributed ledger. The service will be streamed through the multi-access edge computing nodes <NUM> with <NUM> connectivity that runs, deep inside the Asian operators virtualized core network applying specific federated network slices with guaranteed QoS. This service will also be delivered through the counter-party operator's <NUM> network and multi-access edge computing nodes <NUM> infrastructure on the US continent and directly onto system panels of autonomous vehicles. This network slice will be made available on both operator platforms, preferably with servers hosted on their respective data centres, specifically for mobile network operators that want to maintain all network services across different operator footprints that require inter-operator agreements.

<FIG> shows a schematic of multi-access edge computing nodes <NUM>, <NUM> that are distributed across the system <NUM> to explain how they reach consensus. With reference to <FIG>, the respective base stations of the multi-access edge computing nodes <NUM>, <NUM> are not shown for the sake of simplicity.

The multi-access edge computing nodes <NUM>, <NUM> shown in <FIG> are witnesses that are allowed to validate new blocks that are to be added into the distributed ledger. As such, the delegated proof of stake principle described in <FIG> does not require for all of the multi-access edge computing nodes of the system to validate a transaction before the distributed ledger is updated with the transaction, thereby allowing for the transaction to be executed. Further, it is also not required for all of the witness multi-access edge computing nodes <NUM>, <NUM> to validate a transaction. Rather, it would be sufficient that a group of these multi-access edge computing nodes <NUM>, <NUM> validate the transaction. In the case of <FIG>, a transaction is validated if <NUM>% of the nodes reach consensus on the transaction, i.e. <NUM> out of the <NUM> multi-access edge computing nodes <NUM>, <NUM> (namely the multi-access edge computing nodes <NUM>, while it is not required for the multi-access edge computing nodes <NUM> to validate the transaction).

<FIG> provides a schematic of a hybrid protocol <NUM> that is used by the distributed ledger of the system <NUM> shown in <FIG>.

The hybrid protocol <NUM> has two layers. The protocol <NUM> used by the first layer was described in <FIG> and provides a main chain <NUM> to record transactions made in respect of goods or services, that are in accordance with terms and conditions of a smart contract. Use cases were described in <FIG>, <FIG> and <FIG>.

The protocol <NUM> is used by the second layer to control one or more side chains <NUM> of data blocks that link to a designated data block of the main chain <NUM> controlled by the protocol <NUM> used by the first layer. The side chains <NUM> can be used to record transactions made in respect of goods or services belonging to a different category from those recorded in the main chain <NUM>. The protocol <NUM> uses algorithms that are based on directed acyclic graph mathematical concepts.

The purpose of the one or more side chains <NUM> is to offload computation off the main chain <NUM> onto the one or more side chains <NUM> of data blocks. While described herein as data blocks, it will be appreciated that they can be understood as data graphs, since directed acyclic graph mathematical concepts are used. The one or more side chains <NUM> of data blocks offloads computation because each of them can be defined by a custom rule-set, which is in accordance with the principles of the protocol <NUM> used by the second layer. This allows for the one or more side chains <NUM> of data blocks to be optimised for applications that require high speeds or lightweight computation, while conserving the main chain <NUM> for applications that require heavyweight computation. Applications that require lightweight computation refer to transactions with no underlying contract or are regulated by an underlying contract where compliance to its terms and conditions are quickly validated by the multi-access edge computing nodes of the system <NUM> shown in <FIG>. Applications that require heavyweight computation refer to transactions that are regulated by an underlying contract where validation of compliance to its terms and conditions takes comparatively more processing power and time.

Each of the one or more side chains <NUM> of data blocks synchronises <NUM> with the main chain <NUM> at a designated data block of the side chain <NUM> (denoted using reference numeral <NUM>) to reconcile records stored in the main chain <NUM> by updating the main chain <NUM> with transactions that are recorded in the side chain <NUM>. The creation of these side chains <NUM> and their synchronisation with the main chain <NUM> is described in more detail in <FIG>.

<FIG> provides a schematic of the interaction of the protocol <NUM> used by the first layer and the protocol <NUM> used by the second layer in the distributed ledger of the system <NUM> shown in <FIG>. This interaction is illustrated on the chained block of data shown in <FIG> and occurs on the second data block <NUM>, which in the example shown in <FIG> is the root node of the side chain <NUM>. The interaction uses a two way peg approach which is described in greater detail below. At the point when one or more of the multi-access edge computing nodes <NUM>, <NUM> (refer <FIG>) is validating the second data block <NUM>, one of these nodes receives a request to create a side chain <NUM> of data blocks that extends from the main chain <NUM> of data blocks (represented using the arrow <NUM> in <FIG>). This causes assets to be moved from the main chain <NUM> to the side chain <NUM> because transactions are to be recorded on the side chain <NUM> and assets are required to effect the transactions. Assets do not necessarily refer to digital currency or tokens, but also include inventory used to effect transactions of goods or services, depending on the data recorded in the main chain <NUM> and the side chain <NUM>. The moved assets are flagged to be locked in the main chain <NUM> of data blocks, which causes such locked assets to be not usable to effect transactions recorded on the main chain <NUM>. To synchronise the main chain <NUM> and the side chain <NUM>, two waiting periods are defined: a confirmation period and a contest period.

The confirmation period of a transfer to the side chain <NUM> is a duration for which an asset must be locked on the main chain <NUM> before it can be transferred to the side chain <NUM>. The purpose of this confirmation period is to allow for multi-signature of the multi-access edge computing nodes <NUM>, <NUM>, i.e. for the witness multi-access edge computing nodes <NUM> to validate the locking of assets in the second data block <NUM>. The obtaining of the multi-signatures of the multi-access edge computing nodes <NUM>, <NUM> makes a denial of service attack in the next waiting period (i.e. the contest period) more difficult. After waiting out the confirmation period, a transaction can be created on the side chain <NUM> referencing proof that it has been validated through consensus of the multi-access edge computing nodes <NUM>, <NUM> on the main chain <NUM>.

The contest period is a duration in which a newly-transferred asset may not be spent on the side chain <NUM>. The purpose of the contest period is to prevent double spending by transferring previously-locked assets. If at any point during this delay, a "conflicting" data block is raised for inclusion into the main chain <NUM> before the witness multi-access edge computing nodes <NUM>, which does not include the data block in which the assets are locked, the conversion is retroactively invalidated.

If there is lack of receipt of the "conflicting" data block, this signifies there is consensus amongst the witness multi-access edge computing nodes <NUM>, which verifies that the second block of data <NUM> with the locked assets is included in the main chain <NUM> (represented using the arrow <NUM> in <FIG>). This causes the main chain <NUM> of data blocks to have at least one data block with a record of locked assets.

While locked on the main chain <NUM>, the assets can be freely transferred within the side chain <NUM> without further interaction with the main chain <NUM>. Transactions, determined to be based on the locked assets, can be recorded into one or more data blocks <NUM> of the side chain <NUM>, without requiring for them to be validated by the protocol described in <FIG> which is in respect of the main chain <NUM>. New transactions recorded into one or more data blocks <NUM> of the side chain <NUM> are validated when each new transaction can approve two previous transactions recorded in earlier data blocks of the side chain <NUM> by referencing these two earlier transactions. Validation at the side chain <NUM> therefore undergoes a simpler validation procedure compared to those validated on the main chain <NUM>.

The locked asset retains its identity as a main chain <NUM> asset, and can only be transferred back to the same main chain <NUM> from which it came. The side chain <NUM> is linked to the data block of the main chain <NUM> with the locked assets, i.e. the second data block <NUM> of the main chain <NUM> is the root node of the side chain <NUM>.

When assets are to be transferred from the side chain <NUM> back to the main chain <NUM>, a peg-out transaction is made on the side chain <NUM>. This transaction is checked by the witness multi-access edge computing nodes <NUM> which sign a transaction spending from a multi-signature wallet they control on the main chain <NUM>. A threshold number (e.g. <NUM>%) of the witness multi-access edge computing nodes <NUM> must sign before the main chain <NUM> transaction becomes valid. The witness multi-access edge computing nodes <NUM> then signs transactions on the side chain <NUM> that destroy a corresponding number of assets on the sidechain <NUM>, effectively transferring the assets from the side chain <NUM> to the main chain <NUM> (represented using the arrow <NUM> in <FIG>).

A use case scenario for the side chain <NUM> is provided as follows.

In one implementation, each sidechain <NUM> is defined by a custom "rule-set" and can be used to offload computations from another chain. Individual sidechains <NUM> can follow different sets of rules from the main chain <NUM>, which means they can be optimised for applications that require extremely high speeds. Sidechains <NUM> can be understood as a discrete graph that is linked to the main chain <NUM> applied through a two-way peg. In this case, a DAG acts as a sidechain <NUM>. where a machine writing transactions on the main chain <NUM> has to send their funds to an output address. Once the tokens are in the output address, they are locked-in. This means that the machine is no longer able to use the tokens. To ensure increased security, communication is sent across the main chain <NUM> and sidechain <NUM> and a waiting period is permitted after the machine's token is moved to the output address. Once the waiting period is over, the token is released to the side chain <NUM>. The machine is then able to spend the tokens on the sidechain <NUM>. When moving from the side chain <NUM> to the main chain <NUM>, the machine sends the coins from the sidechain <NUM> to an output address where they are locked. After the waiting period is over, an equivalent number of tokens are transferred to the main chain <NUM>. This acts as a two way synchronization between the two hybrid distributed ledgers, the first being realised by the main chain <NUM> and the second being realised by the side chain <NUM>. The sidechain <NUM> provides many benefits: (<NUM>) The DAG sidechain <NUM> is independent from the main chain <NUM> that is firewalled, and is responsible for their own security without major risk to the integrity of the main chain <NUM>. (<NUM>) DAG is known for scalability through parallel transactions in its own nature, with DAG being a layer <NUM> scaling that allows transactions to be conducted off the main chain <NUM>, this can be scaled further with IoT. Thus, taking pressure off the main chain <NUM> and allows the main chain <NUM> to further accelerate transactions. (<NUM>) Supports two way pegged assets (side chains <NUM> issue an asset that is backed at a deterministic exchange rate to the main chain <NUM> assets) with interoperability. (<NUM>) The option to include a federated sidechain to add nodes in-between the main chain <NUM> and the side chain <NUM> through consensus.

<FIG> provides a schematic of a multi-access edge computing node cluster <NUM> comprising several multi-access edge computing nodes <NUM>, where each is configured to support data block deployment (both on the main chain <NUM> and the side chain <NUM>, confer <FIG> and <FIG>) in accordance with the present invention to allow diverse workload, orchestration and governance that are policy driven. Each multi-access edge computing nodes <NUM> has an automation platform block <NUM> that serves as an operating interface to communicate with the distributed ledger. such as to check its status and to execute instructions. An overview of functions provided by the automation platform <NUM> is provided below.

Smart contracts exist as one or more decentralised applications or distributed ledger applications that run on an application layer <NUM>. These smart contracts are written in code that is compliant with rules of an application interface layer <NUM>, so that the smart contracts can work with the distributed ledger provided by die deployed data blocks. Examples of smart contracts include applications that enable loT services to tap into the blockchain deployed by the multi-access edge computing nodes <NUM>, these services including, but not limited to. augmented reality (AR), virtual reality (VR) or facial recognition.

A management block <NUM> comprises a smart policy engine block <NUM>, a smart contracts block <NUM> and a virtual machine (VM) block <NUM>. With reference to <FIG> and <FIG>, die smart policy engine block <NUM> determines which of the protocol <NUM> of the first layer and the protocol <NUM> of the second layer is used to process smart contracts. When the smart contracts employ encryption to shield sensitive data (like personal particulars of parties executing the smart contracts and digital wallets used to fund them), the smart policy engine block <NUM> also processes the output of zero knowledge protocols that are supported by each of the multi-access edge computing nodes <NUM>, these protocols being described in greater detail in <FIG>. The smart policy engine block <NUM> thus helps to manage data blocks that get generated from transactions effected by smart contracts written into the chained data blocks. In one implementation, where access to a dedicated processor is available (described later in <FIG>), the smait policy engine block <NUM> also allocates computational load between the dedicated processor and a stock processor of the multi-access edge computing node <NUM>. The virtual machine block <NUM> is used to provide a runtime environment to provide a system of data manipulated rules that need to be followed to create compliant smart contract.

A storage block <NUM> manages the recordation of smart contract transactions into data blocks into the distributed ledger (either that of the main chain <NUM> or the side chain <NUM>). The storage block <NUM> also manages peripheral data associated with the smart contract transaction, such as but not limited to an identity of IoT devices that are parties to the smart contract transaction and data generated by the decentralised applications that run on the application layer <NUM>. The data blocks are stored in accordance with any peer-to-peer distributed file system standard, such as Interplanetary File System (IPFS) and "Ceph" from Redhat®. Such a standard supports the hybrid protocol described in <FIG> and <FIG>.

A messaging block <NUM> is used for data communication or to enter instructions.

<FIG> provides a schematic of multi-access edge computing node clusters <NUM>, <NUM> and <NUM>, each residing in different regions A. The distributed ledger DLT <NUM> that the clusters <NUM>, <NUM> and <NUM> host, in accordance with the present invention, is schematically shown.

<FIG> shows an ecosystem of interconnected multi-access edge computing node clusters <NUM>, <NUM> and <NUM> in a federated network that uses container orchestration <NUM>. In more detail, each node of the clusters <NUM>, <NUM> and <NUM> runs a container image which is a lightweight, standalone, executable package of software that includes everything needed to run the distributed ledger: code, runtime, system tools, system libraries and settings. Container orchestration <NUM> provisions. schedules and manages containers at scale for decentralized applications/distributed ledger applications (DApps) residing in such containers.

DApps services are orchestrated across the multi-access edge computing node clusters <NUM>, <NUM> and <NUM>. A federated container is where these containers are managed in clusters, so that federated container orchestration <NUM> is present since these multi-access edge computing node clusters <NUM>, <NUM> and <NUM> may belong to different operator networks. The federated container orchestration <NUM> may be realised by open source operating system level virtualization.

Federated container orchestration <NUM> allows for consistent deployment of DApps in each multi-access edge computing node of the clusters <NUM>, <NUM> and <NUM>, therefore allowing the DApps to perform efficiently and reliably. Extrapolating, federated container orchestration <NUM> facilitates deployment of a suite of distributed ledger applications across the multi-access edge computing node clusters <NUM>, <NUM> and <NUM>, wherein each of the applications is configured to interface with the distributed ledger DLT <NUM>. That is, the suite of distributed ledger applications is already coded to work on the distributed ledger DLT <NUM> and output data in a compatible format for inclusion into the chained data block shared by the distributed ledger DLT <NUM>. As earlier explained, distributed ledger applications are programs coded to support smart contracts written into the distributed ledger DLT <NUM>. Under federated container orchestration <NUM>, the suite of distributed ledger applications are coded to comply with regulations imposed in a jurisdiction to which each of the multi-access edge computing node clusters <NUM>, <NUM> and <NUM> belongs. That is, should a contract be executed between a party in region A and a party in region B. regulatory requirements in both regions A and B are automatically met. since a distributed ledger application supporting the execution of the contract in region A complies with regulatory requirements of region A, while a distributed ledger application supporting the execution of the contract in region B complies with regulatory requirements of region B. A solution to implement cross border transactions is thereby implemented. Additionally, each cluster <NUM>, <NUM> and <NUM> shares service discovery, so that a back-end resource is accessible from any other cluster. If one container fails, another one will be created automatically.

It will be appreciated that the various functions described thus far (e.g. data block generation, smart contract execution and smart policy engine management) are controlled through a central processing unit (CPU) of the multi-access edge computing node. The CPU is formed by one or more core processors having such functionality after software installation that writes instructions that perform the necessary arithmetic and logic operations to execute the functions into the register of the operating system of the multi-access edge computing node. The term "stock processor" refers to such a CPU, which is part of standard technical specifications of the multi-access edge computing node.

<FIG> shows a non-exhaustive schematic of functions <NUM> that are executed by the stock processor of each of the multi-access edge computing nodes <NUM>, <NUM> and <NUM> of <FIG> when implementing a distributed ledger DLT <NUM>. A schematic of a dedicated processor <NUM> designed to share the computational load of the stock processor of the multi-access edge computing nodes <NUM>, <NUM> and <NUM> to execute these functions is also shown. The dedicated processor <NUM>, as opposed to the stock processor, is a processor that is specifically designed to share the computationally heavy workload of the stock processor encountered during data block deployment. As such, the architecture of the dedicated processor <NUM> is equipped with logic partitions that are catered for such data block deployment.

The functions <NUM> include determination of a consensus mechanism <NUM>, transaction shielding <NUM>. node management <NUM> and a quantum key generator <NUM>.

With reference to <FIG> and <FIG>, the consensus mechanism <NUM> refers to offloading computation workload (encryption / decryption) that occurs when executing the consensus mechanism described in <FIG>, <FIG> and <FIG>.

Transaction shielding <NUM> refers to addressing privacy and security concerns in the distributed ledger DLT <NUM>, through the use of zero knowledge protocols. ZKP allow entities to store only the proof of the transaction on a node. They keep the sensitive data to themselves, while still maintaining confidence in a connected record of provenance.

A zero-knowledge protocol is a method by which one party (the prover) can prove to another party (the verifier) that something is true, without revealing any information apart from the fact that this specific statement is true. Zero-knowledge proofs (ZKP) validate the truth of something without revealing how the truth is known or share the content of this truth with the verifier. This principle is based on an algorithm that takes some data as input and returns either 'true' or 'false'. ZKP must satisfy three criteria:.

The first two of these are properties of more general interactive proof systems. The third is what makes the proof zero-knowledge.

A zero-knowledge protocol, in line with the above principles, is applied by the transaction shielding <NUM> function when the multi-access edge computing nodes <NUM>, <NUM> and <NUM> detect that a current transaction for recordation as a new data block into the distributed ledger DLT <NUM> contains shielded data (e.g. an identity of the parties to a smart contract transaction ; details of a digital wallet used to fund the smart contract transaction: messages or set of instructions between both or multiple parties on the distributed ledger) to authenticate the shielded data. Authentication of the shielded data reduces to arithmetic operations where an output of logic level "<NUM>" or "<NUM>" determines whether the content of the shielded data is known. The output of the zero knowledge protocol determines whether the current transaction is able to proceed with validation (i.e. can be recorded as a new data block into the blockchain).

When either or both of the stock processor and the dedicated processor <NUM> of the multi-access edge computing nodes <NUM>, <NUM> and <NUM> detects that shielded data is present, these processor(s) identifies existence, within the current transaction, of statements designed to prove a truth about whether content of the shielded data is known, with the shielded data being masked or encrypted. Such statements serve as means to evidence that a transaction is sound because the shielded data is masked and cannot be analysed to make such a decision. The identified statements may be formulated depend on the principles of the zero-knowledge proof upon which algorithms are based. The algorithms accept specific data as input and returns whether the identified statements are either 'true' or 'false'. The processor(s) evaluates a truth of the identified statements and if determined that it is true that the content of the shielded data is known, authenticates the shielded current transaction. While absolute certainty is not guaranteed, the statements are formulated such that affirmative results reflect a high degree of probability of the current transaction being sound, which then allows for the current transaction to be recorded as a new data block. as set out in <FIG>, <FIG> and <FIG>.

When evaluating the truth of the identified statements, the processor(s) of the multi-access edge computing nodes <NUM>, <NUM> and <NUM> is further configured to determine that the identified statements are evaluated to be true by each of a group of external multi-access edge computing nodes. That is, taking the perspective of the multi-access edge computing node <NUM> as an example, consensus is reached by each of the multi-access edge computing nodes <NUM> and <NUM> that is also evaluating the truth of the one or more identified statements. The consensus may follow the approach as described in <FIG>.

A first approach bases the statements used to establish the validity of the current transaction on a zero-knowledge Succinct Non-Interactive ARgument of Knowledge (zk-SNARK). This is a protocol which creates a framework in which the current transaction - submitted for validation by a multi-access edge computing node (e.g. <NUM>, see <FIG>) called prover - can quickly convince other multi-access edge computing nodes (e.g. <NUM> and <NUM>, see <FIG>) - called verifier - that the prover knows a secret without revealing anything the secret.

The protocol realises circuits with inputs of <NUM> or <NUM> and an output of <NUM> or <NUM>. The prover knows a string (<NUM>. , <NUM>) that will result in a <NUM> output. The prover's secret is this string, which in one implementation is based on the details of the data that is being shielded and in another implementation may be arbitrarily generated. In order to convince the verifier that the prover knows a string that has an output of <NUM>, the prover gives a proof π to the verifier. The verifier checks this proof. If the proof is correct, the verifier can be sure that the prover knows a correct string.

A Quadratic Arithmetic Program (QAP) provides the prover with tools to construct the proof π for the claim that the prover knows a valid assignment (a,. , aN ) ∈ FN for a circuit C. A QAP Q(C) := (A, B, C, Z) for a given arithmetic circuit C provides three sets of polynomials <MAT> with coefficients in F, and a target polynomial Z(z) ∈ F(z) such that: The polynomial Z(z) divides the polynomial <MAT> if and only if (a<NUM>,. , aN ) is a valid assignment for the circuit C. The prover constructs P(z) for his proof π, and the verifier can check the divisibility property of P(z) by Z(z).

Another approach uses a one-time trusted setup to generate a private/public key pair that is used to generate statements used to establish the validity of the current transaction. The private part is destroyed and from the public part another key pair is generated, producing a proving key and a verification key. The proving key and the verification key are distributed to provide a common reference shared between the prover and the verifier. A current transaction to be recorded into the distributed ledger of the multi-access edge computing nodes <NUM>, <NUM> and <NUM> contains a computation created from the distributed prover key, for example by using a given public input and the prover key to generate a proof. The processor(s) of the multi-access edge computing nodes <NUM>, <NUM> and <NUM>, in realising its role as the "verifier", is configured to obtain the distributed verifying key that corresponds to the distributed prover key. The processor(s) evaluates the computation using the distributed verifying key and permits for the validation to proceed (i.e. for a new data block to be recorded) in response to the evaluation of the computation producing a correct output.

A second approach to evaluate the truth of the statements used to establish the validity of the current transaction uses an interactive approach.

An interactive proof system <P, V> for an algorithm L is zero-knowledge if for any verifier V* there exists an expected simulator S such that <MAT>.

The definition states that an interactive proof system <P, V> is zero-knowledge if for any verifier V* there exists an efficient simulator S that can essentially produce a transcript of the conversation that would have taken place between P and V* on any given input. Therefore, having a conversation with P cannot teach V* to compute something she could not have computed before. The string z in the definition plays the role of "prior knowledge" (including the random coins of V*); V* cannot use any prior knowledge string z to mine information out of its conversation with P because the requirement is that if S is also given this prior knowledge then it can reproduce the conversation between V * and P just as before.

In the interactive approach, the processor(s) of the multi-access edge computing nodes <NUM>, <NUM> and <NUM> is configured to iterate the identified statements through at least one test: and conclude that the statements are true when a majority of the iterations produce a consistent result.

Turning to node management <NUM>. this refers to monitoring operation of the dedicated chip <NUM>, such as its register 1018A, RAM 1018B and QKD (Quantum Key Distribution) register 1018C. The register 1018A holds a unique ID of the dedicated chip <NUM>. This ID is written into the register 1018A during manufacturing. The same ID is protected and stored on the DLT <NUM>. It is possibility to add more than one register 1018A into the dedicated chip <NUM>.

The RAM 1018B provides cache for the dedicated chip <NUM>. The QKD register 1018C stores cryptographic keys used by the dedicated chip <NUM>, the stock processor or both.

The quantum key generation <NUM> is responsible for selecting a zero knowledge protocol from the QKD register 1018C for use when analysing transactions with shielded data.

When a transaction is to be recorded into the distributed ledger DLT <NUM>, the computation required can be drawn from both the processor of the multi-access edge computing nodes <NUM>, <NUM> and <NUM> and the dedicated processor <NUM>. The dedicated processor <NUM> is designed to share the computational load of the stock processor of the multi-access edge computing nodes <NUM>. <NUM> and <NUM> by being partitioned into logic blocks <NUM>, <NUM> and <NUM>. Each block has electronics designed to share execution of a respective one of the functions of the processor through a combination of suitably connected logic gates. In an ASIC (application-specific integrated circuit) <NUM> implementation, a semiconductor substrate is fabricated with logic gates from a library of components in accordance with a circuitry schematic that is specifically catered to support the distributed ledger DLT <NUM>.

An encryption/decryption accelerator block <NUM> shares computational load with the consensus mechanism <NUM>. A ZKP (zero knowledge protocol) accelerator block <NUM> shares computational load with the transaction shielding <NUM>. A OID Register/Secure RAM/QKD Register block provides storage for data associated with the node management <NUM> and the QKD generator <NUM>. Communication between the dedicated processor <NUM> and the processor of the multi-access edge computing nodes <NUM>, <NUM> and <NUM> is through a high speed bus <NUM>. The high speed bus <NUM> may run on any one or more of the following connection protocols: USB2. PCIe, SATA.

<FIG> shows a layout of the dedicated processor <NUM> of <FIG>. The dedicated processor <NUM> is for installation at a multi-access edge computing node located within a cellular coverage area supported by a base station of a mobile network operator, such as any one of the multi-access edge computing nodes <NUM>, <NUM> and <NUM> and their associated base stations <NUM>, <NUM> and <NUM> described in <FIG>. The dedicated processor <NUM> may be provided as a removable dongle, mounted on a printed circuit board or integrated to a motherboard or electronic circuit board on which the stock processor of the multi-access edge computing nodes <NUM>, <NUM> and <NUM> is mounted, through the high speed bus <NUM> mentioned in <FIG>.

Within a board <NUM> on which the dedicated processor <NUM> is mounted, the dedicated processor <NUM> has electronics divided into logic partitions spread over a secure area <NUM> and a non-secure area <NUM> of a chip boundary <NUM>. These electronics include numerous elementary logic gates of AND, OR, XOR, NOT. NOR and XNOR configuration that are suitably connected to realise the function required from each logic partition.

The board <NUM> has board level devices <NUM>, a power supply <NUM> to power the components of the dedicated processor <NUM> and an external clock <NUM>.

The non-secure area <NUM> has its own power segment <NUM>, a generic interface <NUM>, a clock <NUM> and a system service <NUM>. Communication between the non-secure area <NUM> and the secure area <NUM> occurs over an APB (advanced peripheral bus) <NUM>.

The components of the secure area <NUM> are as follows: a processor core <NUM>. an on-chip RAM <NUM>, an on-chip storage <NUM>, direct memory access (DMA) modules <NUM> and <NUM>, error correction code memory <NUM> (for correcting internal data corruption), secure boot ROM <NUM>, a true random number generator (TRNG) <NUM>, a one time programmable (OTP) section <NUM> providing one or more areas where each can be used to store data like the serial number of the dedicated chip with interconnection fuses being subsequently blown, and encryption modules: SHA-<NUM><NUM>, SHA-<NUM><NUM>, ZKP <NUM>; RSA <NUM> and AES <NUM>.

The processor core <NUM> communicates with the encryption modules over an advanced high performance bus (AHB) <NUM>. The SHA-<NUM><NUM> and SHA-<NUM><NUM> modules provide the secure hash algorithms used to hash data blocks in the blockchain described in <FIG>. <FIG> and <FIG>. The ZKP <NUM> module provides the zero knowledge protocols to process transactions having shielded data, as described in <FIG>. The RSA <NUM> module provides Rivest-Shamir-Adleman compliant algorithms, while the AES <NUM> module provides advanced encryption standard algorithms that may be used during processing of a transaction for recording in the blockchain. The processor core <NUM> also uses the AHB <NUM> to communicate with external components (such as the stock processor of a multi-access edge computing node) through a high speed interface <NUM> or to the non-secure area <NUM> through a bridger <NUM>.

With reference to <FIG>. one or more components of the secure area <NUM> is called upon to facilitate computation required to be undertaken by the stock processor to realise the functions <NUM>. For instance, one or more components of the secure area <NUM> become activated to provide a ledger management partition that is configured to share computational load of the stock processor of the multi-access edge computing node to include a new data block, to record a current transaction in respect of a good or service, into a chained data block stored in at least one memory of the multi-access edge computing node on which the dedicated processor <NUM> is installed. The new data block is recorded in response to a signature, generated from processing the data of the current transaction with coded data of past transactions stored in the chained data block, being validated by a group of external multi-access edge computing nodes which are trusted. The ledger management partition may include the processor core <NUM> sending instructions to the SHA-<NUM><NUM>, SHA-<NUM><NUM>, RSA <NUM>, AES <NUM> and ECC <NUM> modules to perform the hashing required to record a new data block is described in <FIG>.

<FIG> and <FIG> describe that the distributed ledger can record a new data block into a main chain <NUM> or a side chain <NUM>. depending on the processing power required to record the new data block. To allow for the implementation of the side chain <NUM>, the ledger management partition may be further configured to share computational load of the stock processor of the multi-access edge computing node to: lock assets in at least one data block of the main chain <NUM>. The dedicated processor <NUM> then records transactions, determined to be based on the locked assets, into one or more data blocks of the side chain <NUM>; and assists to link the side chain <NUM> to the data block of the main chain <NUM> with the locked assets.

One or more components of the secure area <NUM> become activated to provide a shielded transaction validation partition that is configured to share computational load of the stock processor of the multi-access edge computing node to process transactions with shielded data, being data which is meant to be kept confidential and not shared.

In the case where the shielded transaction validation partition detects transactions with such shielded data, The shielded transaction validation partition uses zero-knowledge proof that seek to authenticate the shielded data through the application of arithmetic operations which reduce to an output of logic level "<NUM>" or "<NUM>" to determine whether the content of the shielded data is known. The output of the zero knowledge protocol determines whether the current transaction is able to proceed with validation (i.e. can be recorded as a new data block into the blockchain). The shielded transaction validation partition seeks to locate statements designed to prove a truth about whether content of the shielded data is known, with the arithmetic operations being applied onto such statements, with the shielded data being masked or encrypted. The identified statements may be formulated depend on the principles of the zero-knowledge proof. If evaluation of the identified statements indicate that it is true that the content of the shielded data is known, this authenticates the shielded data and allows for the current transaction to be recorded as a new data block, as set out in <FIG>, <FIG> and <FIG>.

When evaluating the truth of the identified statements, the shielded transaction validation partition may be further configured to determine that the identified statements are evaluated to be true by each of a group of external multi-access edge computing nodes. That is, consensus is reached by each of the multi-access edge computing nodes that is also evaluating the truth of the one or more identified statements.

One approach bases the statements used to authenticate the hidden data is based on a zero-knowledge Succinct Non-Interactive ARgument of Knowledge (zk-SNARK). For example, a one-time trusted setup to generate a private/public key pair is used to generate statements used to establish the validity of the current transaction. The private part is destroyed and from the public part another key pair is generated, producing a proving key and a verification key. The proving key and the verification key are distributed to provide a shared common reference. A current transaction to be recorded into the distributed ledger contains a computation created from the distributed prover key, for example by using a given public input and the prover key to generate a proof. The shielded transaction validation partition is configured to obtain the distributed verifying key that corresponds to the distributed prover key. The shielded transaction validation partition evaluates the computation using the distributed verifying key and permits for the validation (i.e. for a new data block to be recorded) to proceed in response to the evaluation of the computation producing a correct output.

Another approach evaluates the truth of the statements used to authenticate the shielded data through an interactive approach. The shielded transaction validation partition may be further configured to iterate the identified statements through at least one test; and conclude that the statements are true when a majority of the iterations produce a consistent result.

In the case where the shielded transaction validation partition detects that a current transaction contains data that requires shielding, the shielded transaction validation partition proceeds to shield such data. The shielded transaction validation partition then formulates statements designed to prove a truth about whether content of the shielded data is known, with the shielded data being masked.

<FIG> provides a flow that demonstrates how a smart policy engine <NUM> (also confer reference numeral <NUM> of <FIG>) operating on a stock processor of a multi-access edge computing node works with the dedicated processor <NUM> of <FIG> to implement the distributed ledgers described in <FIG>, <FIG> and <FIG>.

At step <NUM>, a transaction takes place, which may be a simple nano transaction (Tx) to be recorded on a side chain (confer <FIG> and <FIG>) or a transaction with smart contract (SC) to be recorded on a main chain. The transactions may or may not require data shielding and its associated zero knowledge protocol.

At step <NUM>, the smart policy engine <NUM> acts as a communication bridge between the distributed ledger <NUM> and the dedicated processor <NUM>. The smart policy engine <NUM> will collect the required tasks and amount of zero knowledge proof (ZKP) to process from the distributed ledger <NUM>.

At step <NUM>, the smart policy engine <NUM> organises the tasks in a pool and assigns ZKP transaction priorities. The smart policy engine <NUM> may split the pools into "Large pool", "Medium Pool" or "Small Pool".

At step <NUM>. the prioritisation setup is completed and instruction sets are sent to the dedicated processor <NUM> one at a time, depending on the policy defined by the smart policy engine <NUM>.

At step <NUM>, the dedicated processor <NUM> includes an internal task mixer that is responsible for issuing jobs to embedded multiple accelerators (acc_1, acc_2_n) inside the dedicated processor <NUM>. The computation is completed within a predefined window. A combinator will collectively combine all the computing results in a batch.

At step <NUM>, the dedicated processor <NUM> sends the results back to the smart policy engine <NUM>.

At step <NUM>, the smart policy engine <NUM> will complete a ZKP masked package that is delivered to the distributed ledger <NUM> for validation.

<FIG> is a schematic of a system comprising a distributed ledger <NUM> that is implemented by a processor of the multi-access edge computing nodes <NUM> and <NUM> of <FIG> sharing computational load with the dedicated processor <NUM> of <FIG>.

With the dedicated processor <NUM> being connected to the stock processor of the multi-access edge computing nodes <NUM> and <NUM>, all functions are boosted. Protocols <NUM> and <NUM> that record transactions of use cases <NUM> and <NUM> into the distributed ledger <NUM> execute faster. Use case <NUM> demonstrates a heavy weight smart contract transaction through layer <NUM> (confer reference numeral <NUM>) and use case <NUM> is a light weight nano transaction through layer <NUM> (confer reference numeral <NUM>) accelerating performance and consensus on the distributed ledger <NUM> supported by the dedicated processor <NUM>.

The incorporation of the dedicated processor <NUM> results in overall lower latency, boosts performance and supports privacy encryption.

<FIG> is a schematic to explain how election of witness multi-access edge computing nodes <NUM> is performed.

In a network <NUM> comprising multi-access edge computing nodes that utilise a distributed ledger, stakeholders <NUM> refer to the machines that hold utility tokens. These stakeholders <NUM> continuously monitor for the best performing multi-access edge computing nodes and vote them to be trusted. The trusted multi-access edge computing nodes become witnesses <NUM> that are allowed to update the distributed ledger with data of new transactions. Consensus has to be reached by a percentage of the witnesses <NUM> (e.g. <NUM> or <NUM> of them). Delegates <NUM> are made up from a consortium of mobile network operators, which have the power to propose changes to the network <NUM> through stakeholder <NUM> voting.

In the application, unless specified otherwise, the terms "comprising", "comprise", and grammatical variants thereof, intended to represent "open" or "inclusive" language such that they include recited elements but also permit inclusion of additional, non-explicitly recited elements. It will also be appreciated that the terms "information" and "data" are used interchangeably, especially when referring to recording transactions into a distributed ledger.

Claim 1:
A multi-access edge computing node (<NUM>) located to utilise radio access network infrastructure of a base station (<NUM>) of a mobile network operator (A) for cellular communication that comprises <NUM> and <NUM> frequency bands, the multi-access edge computing node comprising
at least one memory to store a chained data block, where each data block is coded with data of a past transaction in respect of a good or service; and
at least one processor configured with functions that:
include a new data block, to record a current transaction in respect of a good or service, into the chained data block in response to a signature, generated from processing the data of the current transaction with the coded data of the past transactions stored in the chained data block, being validated by other multi-access edge computing nodes, wherein the multi-access edge computing node and the other multi-access edge computing nodes are trusted, and communicate over a common channel,
wherein data in respect of transactions is received through cellular connection provided by the base station.