Multi-access Edge Computing Node and Method for Deploying a Set of Distributed Accounting Applications

Abstract

The present invention discloses a multi-access edge computing node and a method for deploying a set of distributed ledger applications. Among them, a multi-access edge computing node located within a cellular coverage area supported by a base station of a mobile network operator is provided. The node includes at least one memory and at least one inventory processor. The memory is used to store chained data blocks, where each data block is encoded with data on past transactions of goods or services. The inventory processor is configured with the following functions: including a new data block for recording the current transaction of goods or services into the chained data block in response to a signature, which is generated by processing the data of the current transaction using the encoded data of past transactions stored in the chained data block and verified as valid by an external group of multi-access edge computing nodes. The multi-access edge computing node and the external group of multi-access edge computing nodes are trustworthy and communicate through a common channel.

Description

Technical Field

[0001] The present invention relates to a multi-access edge computing (Edge Computing) node with a distributed ledger (ledger). Background Art

[0002] In recent years, decentralized ledger technology has received much attention due to its application flexibility: it provides an architecture for deploying utility tokens with built-in smart contracts.

[0003] However, blockchain-supported transactions are subject to some limitations. Due to the nature of transactions being verified as valid therein, which requires multiple machines to reach a consensus, this results in latency when processing a large number of transactions simultaneously. According to an article published by Forbes on December 10, 2017, such latency will pose difficulties in scaling blockchain technology to support Internet of Things (IoT) applications, where the IoT market is expected to grow exponentially from $157 billion in 2016 to $457 billion in 2020. The essence of blockchain technology is a decentralized ledger, which has a security vulnerability called the "51% attack", where if more than half of the machines verify a ledger containing incorrect records as valid, then dishonest transactions may also be wrongly processed as valid transactions. Privacy is also an issue because past transactions can be obtained, from which identifying information can be obtained.

[0004] Although existing methods attempt to improve latency and enhance the security of blockchain technology, many of these methods address these drawbacks unilaterally without fully leveraging the capabilities of blockchain technology.

[0005] The present invention aims to address the above drawbacks and provide a system that more effectively utilizes blockchain technology. Summary of the Invention

[0006] According to one aspect of the present invention, there is provided a multi-access edge computing node located within a cellular coverage area supported by a base station of a mobile network operator. The multi-access edge computing node includes: at least one memory for storing chained data blocks, where each data block is encoded with data on past transactions of goods or services; and at least one stock processor configured with the following functions: including a new data block, recording a current transaction of goods or services into the chained data block in response to a signature generated by processing data of the current transaction by using encoded data of past transactions stored in the chained data block and verified as valid by an external group of multi-access edge computing nodes, where the external group of multi-access edge computing nodes and the multi-access edge computing node are trustworthy and communicate through a common channel.

[0007] According to another aspect of the present invention, there is provided a dedicated processor 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. The dedicated processor has electronics divided into logical partitions, the logical partitions including an accounting management partition configured to share the computational load of the inventory processor of the multi-access edge computing node to include new data blocks for recording current transactions regarding goods or services into a chained data block stored in at least one memory of the multi-access edge computing node on which the dedicated processor is installed, in response to a signature generated by processing data of the current transaction with encoded data of past transactions stored in the chained data block and verified as valid by a group of trusted external multi-access edge computing nodes; and a masked transaction verification partition configured to: generate masked data including data of the current transaction determined to need masking; and formulate a statement aimed at proving the authenticity of whether the content of the masked data in the masked masked data is known. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Representative embodiments of the present invention will be described below by way of example only with reference to the accompanying drawings, in which:

[0009] Figure 1 is a schematic diagram of a part of a system including access points, each access point supporting a corresponding multi-access edge computing node.

[0010] Figure 2 shows a protocol for constructing a chained data block in an accounting shared by each multi-access edge computing node of Figure 1 the.

[0011] Figure 3 shows an example of the use of a smart contract related to supply chain management.

[0012] Figure 4 shows an example of the use of a smart contract involving streaming media from a source to a receiving device.

[0013] Figure 5 is a schematic diagram showing multi-access edge computing nodes distributed across a system, for explaining how they reach a consensus.

[0014] Figure 6 provides a Figure 1 schematic diagram of a hybrid protocol used for distributed accounting of the system shown.

[0015] Figure 7 provides a Figure 1 schematic diagram of the interaction of protocols used for distributed accounting of the system shown.

[0016] Figure 8Provides a schematic diagram of a multi-access edge computing node cluster, which is configured to support data block deployment to allow diverse workloads, orchestration, and governance.

[0017] Figure 9 Provides a schematic diagram of a multi-access edge computing node cluster, with each cluster residing in a different region through federated container orchestration.

[0018] Figure 10 Is performed by Figure 1 Schematic diagrams of functions executed by the inventory processors of each multi-access edge computing node and of a dedicated processor designed to share the computational load of the inventory processors of the multi-access edge computing nodes to execute these functions.

[0019] Figure 11 Illustrates Figure 10 The architecture of the dedicated processor.

[0020] Figure 12 Provides a flowchart showing how the intelligent policy engine 1210 running on the inventory processor of a multi-access edge computing node works together with Figure 11 The dedicated processor.

[0021] Figure 13 Is a schematic diagram of a system including a distributed ledger, which is implemented by the processor of a multi-access edge computing node of Figure 1 And shares the computational load with the dedicated processor of Figure 11 The multi-access edge computing node.

[0022] Figure 14 Is a schematic diagram explaining how to perform the election of a witnessed multi-access edge computing node. Detailed implementation

[0023] In the following description, various embodiments are described with reference to the accompanying drawings, where the same character markings generally refer to the same components in different drawings.

[0024] Broadly speaking, the present application relates to accounting distributed across multi-access edge computing nodes. The accounting is a database storing records of monitored transaction entries, distributed across each multi-access edge computing node hosting a copy. In the context of Internet of Things applications, transactions can be automatically initiated by the Internet of Things devices themselves (i.e., machine-to-machine or M2M) as long as certain conditions are met; or human intervention may be required, such as an operator operating the Internet of Things device at one end (machine-to-human or M2H) or operators operating the Internet of Things devices at each end (human-to-human, H2H).

[0025] The distributed accounting is also synchronized. When one of the hosted accountings is updated to record data of a new transaction into the data of past transactions, the hosting multi-access edge computing node checks whether the updated accounting is consistent with the accountings hosted in other multi-access edge computing nodes updated with the data of the same new transaction. When at least a majority of the other multi-access edge computing nodes are consistent with the updated accounting, machine-to-machine verification is effective. In one embodiment, the Delegated proof of stake (DPoS) consensus is used, where agreement is sought from a percentage (e.g., 66%) of a selected group of multi-access edge computing nodes (referred to as "witnesses"). The selected group of multi-access edge computing nodes are nodes that produce trustworthy results, i.e., those multi-access edge computing nodes that produce a consistent updated accounting when each of them records a new data block containing data of a new transaction. The group of multi-access edge computing nodes seeking agreement are voted on by the multi-access edge computing nodes of the stakeholders. These stakeholders are multi-access edge computing nodes with utility tokens, which provide a percentage ownership of the platform created by the system of multi-access edge computing nodes hosting the distributed accounting. Since only trustworthy multi-access edge computing nodes validate the updated accounting as effective, this reduces the likelihood of a "51% attack" from multi-access edge computing nodes using the known "Proof Of Work" technology. Compared with the "Proof Of Work" method, only a selected number of multi-access edge computing nodes validating the updated accounting as effective also reduces latency. In one embodiment, only 66% of the selected group of multi-access edge computing nodes perform the accounting update.

[0026] Each multi-access edge computing node is located within a cellular coverage area supported by a base station of a mobile network operator, e.g., adjacent to the base station. According to the technical standards defined by the European Telecommunications Standards Institute (ETSI) and 3GPP (3rd Generation Partnership Project) regarding multi-access edge computing, the multi-access edge computing node operates under 4G and 5G frequency bands. Thus, the multi-access edge computing node is placed near the base station to utilize the radio access network infrastructure of the base station, which provides cellular communication in these 4G and 5G frequency bands, such that the multi-access edge computing node operates under broadcast network conditions rather than under dedicated network conditions. An example of the operating spectrum is within 24 GHz to 86 GHz to utilize lower latency and higher throughput as compared to operation in this spectrum.

[0027] Generally, the multi-access edge computing node provides for multi-access edge computing, which is a network architecture that supports greater computing and storage capacity at the network edge as compared to the network architectures available to interconnected computer systems within the network, e.g., a central data center or a cloud location. Traditional distributed ledgers hosted on such network resources experience latency before transactions can reach these distributed ledgers to be processed and thus cannot effectively scale the processes that seek to rely on platforms running such distributed ledgers. Instead, hosting the distributed ledger at the network edge can utilize the lower latency and better performance provided by multi-access edge computing to allow task processing to be closer to the end-user device. Thus, the multi-access edge nodes implemented according to the present invention and their hosted distributed ledgers provide a platform that is advantageous for performing transactions on Internet of Things (IoT) devices, i.e., any device embedded with electronics capable of enabling the device to collect and exchange data regarding transactions, provided that the device can communicate with any multi-access edge computing node, e.g., via a cellular connection provided by a base station supporting the multi-access edge computing node.

[0028] A mobile network operator refers to any telecommunications company that has the right to use a base station to broadcast within an allocated spectrum, where the base station provides the infrastructure to create cells in a cellular network. Thus, the base station allows the mobile network operator to perform wireless data communication on the allocated spectrum and also allows a gateway to a core network served by the base station, where the core network is part of an interconnected computer system (e.g., the Internet).

[0029] In addition to operating a protocol that specifies how to achieve consensus in its distributed ledger, each multi-access edge computing node also operates the following protocols, where each multi-access edge computing node communicates over a common channel, such as the communication path used by one base station to communicate with another base station. This limits communication on the direct communication path used between base stations and reduces latency time, as opposed to routing communication through a core network. This is in contrast to distributed ledgers operating on radio access networks.

[0030] The following provides details of an implementation of the multi-access edge computing node, which is beneficial for enhancing the distributed ledger capabilities hosted by the multi-access edge computing node. Generally speaking, the multi-access edge computing node has a stock processor (as a standard server processor), and a dedicated processor (a specially designed processor separate from the stock processor), which is responsible for updating the distributed ledger when incorporating new data blocks. The policy engine is responsible for determining the algorithm used to verify transactions recorded in the distributed ledger, and for processing the output of the zero-knowledge protocol, which is used when a transaction containing masked data is to be recorded in the distributed ledger. The policy engine can further be configured to determine whether the calculations for verifying an update to the distributed ledger are performed by the stock processor or by the dedicated processor.

[0031] Figure 1 Is a schematic diagram of a part of system 100 including base stations 102, 104, and 106, where each base station supports a corresponding multi-access edge computing node 102M, 104M, and 106M, such that each multi-access edge computing node 102M, 104M, and 106M can utilize the data transmission and reception capabilities of the cellular coverage provided by their respective base stations 102, 104, and 106. In one implementation, this is achieved by positioning each of the multi-access edge computing nodes 102M, 104M, and 106M within the cellular coverage area of its corresponding base station 102, 104, and 106. In another implementation, this is achieved by positioning the multi-access edge computing nodes 102M, 104M, and 106M at or near their corresponding base stations 102, 104, and 106. For simplicity, not all other multi-access edge computing nodes and their corresponding associated base stations are shown in the schematic diagram of system 100.

[0032] In one embodiment, base stations 102, 104, and 106 belong to the same mobile network operator. Communication between each of the multi-access edge computing nodes 102M, 104M, and 106M for processing transactions is initiated by a subscriber to the mobile network operator. In another embodiment, each of base stations 102, 104, and 106 belongs to a different mobile network operator. Communication between each of the multi-access edge computing nodes 102M, 104M, and 106M for processing transactions complies with the terms of an operator roaming partnership between different mobile network operators, where the transactions are initiated by a subscriber to each respective mobile network operator.

[0033] In yet another embodiment, base stations 102, 104, and 106 belong to a third party, whereby different mobile network operators use each of the base stations to facilitate communication between each of the multi-access edge computing nodes 102M, 104M, and 106M for processing transactions initiated by subscribers to different mobile network operators. For example, mobile network operators A, B, and C may use base station 102 such that multi-access edge computing node 102M will first receive a notification if the transaction is initiated by a subscriber of mobile network operators A, B, and C within the cellular coverage area of base station 102.

[0034] Communication for validating the effectiveness of a transaction (such as a transaction occurring at an electric vehicle (EV) charging station 114, where the two parties to the transaction are a charging station operator and an EV operator) between multi-access edge computing node 102M and other multi-access edge computing nodes 104M and 106M will occur over communication paths 108, 110, where the base stations 102, 104, and 106 communicate data with each other over the communication paths 108, 110 rather than routing through the mobile network operator core network 112. A common channel established along the communication paths 108, 110 for isolating communication between multi-access edge computing nodes 102M, 104M, and 106M is used to reduce the latency for processing the transaction (such as a transaction between a charging station operator and an EV operator). Even in the case of validating a cross-border transaction, where communication with the mobile network operator core network 112 is required to obtain resources (such as obtaining a currency exchange rate for a cross-border transaction, i.e., when the jurisdiction of the utility tokens owned by a party at one end is different from the jurisdiction of the party at the other end), the common channel along the communication paths 108, 110 can still be used by multi-access edge computing nodes 104M and 106M to validate the cross-border transaction. The communication paths 108, 110 can be implemented using wired or wireless devices.

[0035] Each of the multi-access edge computing nodes 102M, 104M, and 106M has at least one memory to store the chained data blocks. The chained data blocks are essentially records of the transfer of ownership during transactions from the first to the most recent, such that the chained data blocks provide an accounting function shared by the multi-access edge computing nodes 102M, 104M, and 106M. Its data structure is a hash pointer that points to the backward-linked transaction blocks. Each block can be identified by a hash generated, for example, using the SHA256 cryptographic hash algorithm on the header of the block. The header of each block references the previous block. Each block contains the hash of its parent in its own header. It results in a chain that goes back to the first block created, also known as the genesis block, linked together by a series of hashes.

[0036] Since system 100 does not have a central entity to authenticate any of its supported transactions, but instead uses machine-to-machine verification, each of the multi-access edge computing nodes 102M, 104M, and 106M relies on the accounting function of the chained data blocks to determine if there are sufficient assets to execute a new transaction; assets refer to, for example, whether there is inventory of the goods or funds in a digital wallet to pay for the goods.

[0037] Figure 2 A schematic diagram of protocol 200 for constructing chained data blocks in each of the multi-access edge computing nodes 102M, 104M, and 106M is shown, and the construction is based on the principle of delegated proof of stake, which is explained in more detail below. To simplify the explanation of the construction of the chained data blocks, Figure 2 it is assumed that each of the multi-access edge computing nodes 102M, 104M, and 106M is trustworthy, i.e., it is one of the witnesses of all multi-access edge computing nodes through majority voting (i.e., including those not Figure 1(those shown in Figure 14 ). These witness multi-access edge computing nodes are responsible for ensuring the integrity of the shared ledger, i.e., they verify that transactions are valid for recording in the shared ledger. The protocol does not require all witness multi-access edge computing nodes, but only a majority of them (e.g., 66%, although any other predetermined percentage can be set) to verify that a transaction is valid. In one embodiment, the number of utility tokens as distributed nodes is limited and owned by stakeholders, where the stakeholders will continuously monitor the multi-access edge computing nodes with the best performance and vote for the ones they trust as witness multi-access edge computing nodes. In one embodiment, there are 101 multi-access edge computing nodes acting as witnesses, and consensus must be reached among 66 or 67 of them. However, in another embodiment, a different number of multi-access edge computing nodes (i.e., not necessarily 101) act as witnesses, and another percentage (i.e., not necessarily 66%) of the witness multi-access edge computing nodes is required to reach consensus. The number of witness multi-access edge computing nodes 104M and 106M and the percentage at which they reach consensus are based on the network settings, which can be determined by parties called "delegated stake", and will be described in more detail later in Figure 14 ). Ensuring ledger consensus within a predetermined percentage of all multi-access edge computing nodes reduces the processing time taken to reach such consensus.

[0038] During initialization, the shared ledger has no content, so the information of the first transaction, "block0data", becomes the content of the first data block 202 (genesis block) to be included in the shared ledger of any multi-access edge computing nodes 102M, 104M, and 106M. The information provided by "block0data" depends on the nature of the transaction being recorded. For example, if the transaction involves the purchase of goods or services, the information can include one or more pointers that can give the following details: the type of goods or services, their cost; details of the digital wallet used to fund it and the balance of the digital wallet thereafter; the inventory from which the goods are withdrawn; and the identities of the parties to the transaction (e.g., the seller and the buyer, and the shipper from the seller to the buyer). If the transaction involves supply chain management, the information can include one or more pointers that can give the following details: the type of goods or services being monitored, their respective cost prices and selling prices; the inventory of the warehouse where the goods are stored; a list of the locations where the goods are to be delivered; the identity of the warehouse where the goods are stored; the identity of the location where the goods are to be delivered; the identity of the party providing the goods; and the identity of the goods or service provider. Such information exists as data (i.e., computer bit strings). The combination of "block0data", the hash value of the previous data block, and a random nonce becomes the input to the hash function. Since there is no previous data block, the previous hash value is "0", making the hash value of the first data block 202 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 always gives the same output string, but any change in the input results in a random change in the output. The application here is to solve a mathematical problem where the output is a specific data format (e.g., starting with a predetermined combination of characters, such as seven zeros or a mix of letters and numbers), so that the random nonce repeatedly changes to produce such an output. In Figure 2 this case, the hash value of the first data block 202 is "0xea34ad...55", which becomes the signature of the first data block 202, where "$#1" is the random nonce found to produce that hash value. Assuming for simplicity that the transaction of "block0data" is the first of its kind, the hash value "0xea34ad...55" is timestamped, joined with the date, serialized with the index value "0" to successfully create the first data block 202 for backward reference from the subsequent chained data blocks. The successful creation of the first data block 202 is broadcast on the communication paths 108, 110, where the base stations 102, 104, and 106 communicate with each other via the communication paths 108, 110 so that a copy of the first data block 202 is saved on each multi-access edge computing node 102M, 104M, and 106M.

[0039] Information on the second transaction, "block1data", which includes the second data block 204 in the shared ledger, is as follows.

[0040] The content of "block1data" varies according to the nature of the second transaction, so the above comments on "block0data" apply equally. The combination of the hash value of the first data block 202 of "block1data" (i.e., "0xea34ad...55") and a random nonce becomes the input to the hash function. In Figure 2 this case, the hash value of the second data block 204 is "0xf6e1da2...deb", which becomes the signature of the second data block 204, where "@$%" is found to be the random nonce used to generate this hash value.

[0041] All the multi-access edge computing nodes 102M, 104M, and 106M will receive a notification of the second transaction seeking to be recorded in the shared ledger, and each node will solve to obtain the signature of the second data block 204. Assuming that the multi-access edge computing node 102M first obtains the signature of the second data block 204, the multi-access edge computing node 102M will broadcast the signature of the second data block 204 to the multi-access edge computing nodes 104M and 106M, which are trusted external multi-access edge computing nodes from the perspective of the multi-access edge computing node 102M. Each of the multi-access edge computing nodes 104M and 106M validates the signature of the second data block 204 by referring to the previously verified valid data block, i.e., the first data block 202 ("block0data"), via the hash value of the first data block. Then, the hash value of the first data block 202 and the random nonce are hashed to determine whether an output with the previously described specific data format (i.e., starting with a predetermined combination of characters, such as seven zeros or a mixture of letters and numbers) is produced. If so, the signature of the second data block 204 is valid, i.e., the multi-access edge computing nodes 104M and 106M reach a consensus. In the case where a consensus is determined, the hash value "0xf6e1da2...deb" is timestamped, dated, and serialized with the index value "1", resulting in the successful creation of the second data block 202. Since the second transaction occurs after the first transaction, the second data block 204 has a later timestamp of "17:17" compared to the timestamp "17:15" of the first data block 202. The successful creation of the second data block 204 is broadcast via the communication paths 108, 110, where the base stations 102, 104, and 106 use these communication paths to communicate data with each other so that each of the multi-access edge computing nodes 102M, 104M, and 106M maintains a copy of the second data block 204.

[0042] The information (block2data) for including the third transaction "block 2 data" as the third data block 206 in the shared ledger follows a process similar to that of including the second transaction "block 1 data" as the second data block 204 in the shared ledger.

[0043] The content of "block 2 data" varies according to the nature of the third transaction, so the above note regarding "block 0 data" also applies. The combination of "block 2 data", the hash value of the second data block 202 (i.e., "0xf6e1da2...deb"), and a random nonce becomes the input to the hash function. In Figure 2 this case, the hash value of the third data block 206 is "0x9327eb1b...36a21", which becomes the signature of the third data block 206, with the random nonce "#!!" that is found to generate this hash value.

[0044] All multi-access edge computing nodes 102M, 104M, and 106M will receive a notification of a third transaction seeking to be recorded in the shared ledger, where each node will solve to obtain the signature of the third data block 206. Again assuming that multi-access edge computing node 102M first obtains the signature of the third data block 206, multi-access edge computing node 102M broadcasts the signature of the third data block 206 to multi-access edge computing node 104M and multi-access edge computing node 106M, which are trusted external multi-access edge computing nodes from the perspective of multi-access edge computing node 102M. Each of multi-access edge computing nodes 104M and 106M validates the signature of the third data block 206 by referring to the previously verified and valid data block, i.e., the second data block 204 ("block 1 data"), via the hash value of the second data block. Then, the hash value of the second data block 204 and a random nonce are hashed to determine whether an output with the previously described specific data format (i.e., starting with a predetermined combination of characters, such as seven zeros or a mix of letters and numbers) is produced. If so, the signature of the third data block 206 is valid, i.e., multi-access edge computing nodes 104M and 106M reach a consensus. In the case where consensus is determined, the hash value "0x9327eb1b...36a21" is timestamped, dated, and serialized with the index value "2", resulting in the successful creation of the third data block 206. Since the third transaction occurs after the second transaction, the third data block 206 has a later timestamp "17:19" compared to the timestamp "17:17" of the second data block 204. The successfully created third data block 206 is broadcast via communication paths 108, 110, where base stations 102, 104, and 106 use the communication paths 108, 110 to communicate data with each other so that each multi-access edge computing node 102M, 104M, and 106M maintains a copy of the third data block 206.

[0045] Back Figure 1 , system 100 is shown to support use cases of smart contracts 122, 124, which are related to the management of power usage, where the power supply from power plant 118 to drone charging station 116 and electric vehicle (EV) charging station 114 can be seen. The smart contract refers to a digital contract, which is a contract whose terms and conditions are programmed into computer code and stored and replicated through a distributed ledger. The deployment of the smart contract to the distributed ledger is done by power plant 118 communicating with the closest multi-access edge computing node 106M. Smart contract 122 for drone charging and smart contract 124 for EV charging can use different terms and conditions, which can be accommodated by the distributed ledgers of multi-access edge computing nodes 102M, 104M, and 106M.

[0046] Figure 1 shows that the EV charging station 114 is near the multi-access edge computing node 102M. Thus, if the transaction (such as charging an electric vehicle) is initiated according to the smart contract 126, access to the transaction processed by the distributed ledger hosted by the system 100 will be through the multi-access edge computing node 102M. Similarly, the drone charging station 116 is near the multi-access edge computing node 104M. Thus, if the transaction (such as charging a drone) is initiated according to the smart contract 128, access to the transaction processed by the distributed ledger hosted by the system 100 will be through the multi-access edge computing node 104M. Refer to Figure 2 , the blockchain in the distributed ledger can be applicable to, for example, meet the consensus protocol on whether the digital wallet has sufficient funds to pay for the requested electricity by analyzing new transactions against past transactions. It should be understood that although only the EV charging station 114 and the drone charging station 116 are shown, any other platform adopting the distributed ledger hosted by the system 100 can also utilize the distributed ledger by accessing the nearest multi-access edge computing node. Each multi-access edge computing node receives notifications of transactions seeking to be recorded in the distributed ledger through the cellular connection provided by its associated base station.

[0047] In addition to managing power usage, other smart contracts that the distributed ledger of the system 100 can support include purchase and sales contracts, credit and debit of digital wallets, resource tracking in the supply chain, streaming of media content, and monitoring of road traffic conditions.

[0048] Figure 3 shows the usage of smart contracts 328 and 330 related to supply chain management, and these smart contracts 328 and 330 are written into the ledgers of the multi-access edge computing nodes 102M, 104M, and 106M. Similar to Figure 2 , the parties (i.e., the main manufacturer 302, the subcontracting manufacturer 304, and the logistics company 306 representing the subcontracting manufacturer 304 to deliver the finished product) communicate the status of the goods to the nearest multi-access edge computing nodes 102M, 104M, and 106M. The smart contract 328 can assist in supply chain management as follows.

[0049] The main manufacturer 302 subcontracts certain manufacturing components to the subcontracting manufacturer 304. They both initiate the smart contract 328 based on the agreed terms and conditions. Then, the subcontracting manufacturer 304 deploys the smart contract 330 with the logistics company 306 to deliver the final product to the main manufacturer 302. All the smart contracts 328 and 330 are recorded on the distributed ledger, through which the main manufacturer 302 can track various events in real time before the arrival of the final goods.

[0050] Figure 4 illustrates the use of smart contract 406, which involves providing streaming media from source 402 to a receiving device (such as a monitor, speaker, or both) within vehicle 410. The base station 102 that supports the multi-access edge computing node 102M can be located in a different region (such as in the United States) from the region of the base station 104 that supports the multi-access edge computing node 104M (such as in Asia), such that a US-based mobile network operator can use base station 102 while an Asia-based mobile network operator can use base station 104. The smart contract 406 is encoded to account for regulatory requirements in the different regions where the parties are located (source 402 in Asia and vehicle 410 in the United States), and digital wallets 406 and 408 are used to secure payments for the media streamed from source 402 to the receiving device within vehicle 410. Similar to Figure 1 , the distributed ledger hosted by the multi-access edge computing nodes 102M and 104M is adapted to satisfy a consensus protocol regarding the status of each of the digital wallets 406 and 408 when processing media streaming by analyzing new transactions against past transactions.

[0051] Network Slicing 414 is deployed by a mobile network operator network function virtualization (NFV) core network. The monitor in source 402 and vehicle 410 become parties to the virtual network, where the virtual network allows the correct level of connectivity, which allows source 402 to communicate with the receiving device within vehicle 410. This is particularly advantageous because IoT may be a customizable element (such as a simple circuit board with the electronics required to perform its specific purpose) rather than a full computing terminal. Since these elements can run their own architectures, the need for them to communicate at high data rates, low latency, and good QoS (Quality of Service) becomes important, which becomes feasible by making them part of a virtual network. The distributed ledger then provides a backbone architecture to ensure that transactions made according to the smart contract can be validly verified, where each of these elements can support these transactions.

[0052] Figure 4The usage example is applicable to the scenario of a joint network slice utilizing 5G technology, which provides the following cross-border intercontinental services. Suppose an autonomous taxi company (located in the United States) has signed a contract with a multimedia advertising company (located in Asia) to provide advertising services within the in-vehicle system. Both companies are located on different continents. There is an open slot for a five-minute advertising campaign. Once the payment verification is valid on the distributed ledger, the multimedia advertising company will initiate a smart contract to the taxi company (reference label 410) through the multi-access edge computing node 102M. The service will be streamed through the multi-access edge computing node 102M with a 5G connection, which operates within the virtualized core network of the Asian operator, and the network guarantees QoS. The service will also be delivered through the 5G network and the architecture of the multi-access edge computing node 104M of the other operator on the American continent and directly to the system panel of the autonomous vehicle. The network slice will be provided on both operator platforms, preferably with servers hosted on their respective data centers, especially for mobile network operators who wish to maintain all network services within the coverage of different operators that require an inter-operator agreement.

[0053] Figure 5 A schematic diagram showing the multi-access edge computing nodes 502M and 504M distributed across the system 100 is presented to explain how they reach a consensus. Refer Figure 1 , for simplicity, the corresponding base stations of the multi-access edge computing nodes 502M and 504M are not shown.

[0054] Figure 5 The multi-access edge computing nodes 502M and 504M shown in are witnesses that allow the verification of the validity of new blocks to be added to the distributed ledger. Therefore, Figure 2 The delegated proof-of-stake principle described in does not require all the multi-access edge computing nodes within the system to verify the validity of the transaction before the distributed ledger updates the transaction, thus allowing the transaction to be executed. Additionally, it is not necessary for all the witness multi-access edge computing nodes 502M and 504M to verify the transaction as valid. Instead, it is sufficient for a group of these multi-access edge computing nodes 502M and 504M to verify the transaction as valid. In Figure 5 's case, if 66% of the nodes reach a consensus on the transaction, that is, 4 out of 6 multi-access edge computing nodes 502M and 504M (i.e., the multi-access edge computing node 504M, without the need for the multi-access edge computing node 502M to verify the transaction as valid).

[0055] Figure 6 Provide Figure 1 A schematic diagram of the hybrid protocol 600 used by the distributed ledger of the system 100 shown in.

[0056] The hybrid protocol 600 has two layers. The protocol 200 used in the first layer is described in Figure 2 and provides a main chain 252 to record transactions of goods or services according to the terms and conditions of smart contracts. Use cases are described in Figure 1 , 3 and 4.

[0057] The protocol 650 is used by the second layer to control one or more side chains 652 of some data blocks, and the data blocks are linked to the designated data blocks of the main chain 252 controlled by the protocol 200 used in the first layer. The side chains 652 can be used to record transactions of goods or services belonging to a different category from the goods or services recorded in the main chain 252. The protocol 650 uses an algorithm based on the mathematical concept of a Directed Acyclic Graph.

[0058] The purpose of one or more side chains 652 is to offload the computations on the main chain 252 to one or more side chains 652 of the data blocks. Although described as data blocks here, it should be understood that they can be understood as data graphs because the mathematical concept of a directed acyclic graph is used. One or more side chains 652 of the data blocks offload computations because each of them can be defined by a custom rule set that conforms to the principle of the protocol 650 used in the second layer. This allows one or more side chains 652 of the data blocks to be optimized for applications that require high-speed or lightweight computations, while reserving the main chain 252 for applications that require heavy computations. Applications that require lightweight computations refer to transactions without a base contract, or some transactions regulated by a base contract, where the compliance with its terms and conditions is quickly verified by the multi-access edge computing nodes of the system 100 shown in Figure 1 . Applications that require heavy computations refer to some transactions regulated by a base contract, where the verification of the compliance with its terms and conditions requires relatively more processing power and time.

[0059] Each of one or more side chains 652 of the data blocks synchronizes 654 with the main chain 252 at the designated data block of the side chain 652 (denoted by the reference numeral 658) to coordinate the records stored in the main chain 252 by updating the main chain 252 with the transactions recorded in the side chain 652. The creation of these side chains 652 and their synchronization with the main chain 252 are described in more detail in Figure 7 .

[0060] Figure 7 A schematic diagram of the interaction between the protocol 200 used in the first layer and the protocol 650 used in the second layer in the distributed ledger of the system 100 shown in Figure 1 is provided. This interaction is in Figure 2shown on the chained data blocks shown in, and occurs on the second data block 204, which is Figure 7 the root node of the side chain 652 in the example shown. This interaction uses a two-way hook method described in more detail below. When one or more of the multi-access edge computing nodes 502M, 504M (see Figure 5 ) are validating the second data block 204, one of these nodes receives a request to create a side chain 652 of data blocks extending from the main chain 252 of data blocks (indicated by the arrow 702 in Figure 7 ). This causes assets to move from the main chain 252 to the side chain 652 because the transaction will be recorded on the side chain 652 and the assets are required to effect the exchange. The assets do not necessarily refer to digital currencies or tokens, but also include inventories used to effect the exchange of goods or services, depending on the data recorded in the main chain 252 and the side chain 652. The moved assets are marked as locked on the main chain 252 of the data blocks, which causes such locked assets not to be available for effecting transactions recorded on the main chain 252. To synchronize the main chain 252 and the side chain 652, two waiting periods are defined: a confirmation period and a competition period.

[0061] The confirmation period for the transfer to the side chain 652 is the duration for which the assets must be locked on the main chain 252 before being transferred to the side chain 652. The purpose of this confirmation period is to allow for multi-signature by the multi-access edge computing nodes 502M, 504M, i.e., for the witness multi-access edge computing node 502M to validate the locking of the assets in the second data block 204. Obtaining multi-signature by the multi-access edge computing nodes 502M, 504M makes it more difficult to deny service attacks during the next waiting period, i.e., the competition period. After waiting for the confirmation period, a transaction can be created on the side chain 652 that references evidence that it has been validated through the consensus of the multi-access edge computing nodes 502M, 504M on the main chain 252.

[0062] The competition period is the period during which the newly transferred assets cannot be spent on the side chain 652. The purpose of the competition period is to prevent double-spending by transferring the previously locked assets. If at any time during this delay period, before the witness multi-access edge computing node 504M, where the computing node 504M does not include the data block in which the assets are locked, a "conflicting" data block is triggered to be included in the main chain 252, then the transfer is retroactively invalidated.

[0063] If no "conflicting" data block is received, this indicates that there is consensus among the witness multi-access edge computing nodes 504M, where the computing node 504M validates that the second data block 204 with the locked assets is included in the main chain 252 (using Figure 7(indicated by arrow 702 in). This results in the main chain 252 of data blocks having at least one data block in which a record of the locked asset is included.)

[0064] When locked on the main chain 252, the asset can be freely transferred within the side chain 652 without further interaction with the main chain 252. It is determined that transactions based on the locked asset can be recorded in one or more data blocks 706 of the side chain 652 without the need to Figure 2 validate them as valid through the protocol regarding the main chain 252 described in. When two previous transactions recorded in an earlier data block of the side chain 652 can be approved by referring to these two previous transactions at each new transaction, the new transaction recorded in one or more data blocks 706 of the side chain 652 is validated as valid. Thus, compared with those verified on the main chain 252, the valid verification at the side chain 652 undergoes a simpler verification process.)

[0065] The locked asset retains its identity as an asset of the main chain 252 and can only be transferred back to the same main chain 252 from which it came. The side chain 652 uses the locked asset to link to a data block of the main chain 252, i.e., the second data block 204 of the main chain 252 is the root node of the side chain 652.)

[0066] When the asset is to be transferred back from the side chain 652 to the main chain 252, a peg-out transaction is conducted on the side chain 652. This transaction is inspected by the witness multi-access edge computing nodes 504M, and the computing nodes 504M sign the transaction to spend from the wallets they control on the main chain 252. A threshold number (e.g., 66%) of the witness multi-access edge computing nodes 504M must sign before the main chain 252 transaction is validated as valid. Then the witness multi-access edge computing nodes 504M sign the transaction on the side chain 652, which will eliminate the corresponding amount of assets on the side chain 652 to effectively transfer the asset from the side chain 652 to the main chain 252 (indicated by Figure 7 arrow 704).)

[0067] The following provides a scenario of an example use of the side chain 652.)

[0068] In one embodiment, each side chain 652 is defined by a custom "rule set" and can be used to offload computations from another chain. The individual side chains 652 can follow different rule sets from the main chain 252, meaning they can be optimized for applications that require extremely high speeds. The side chain 652 can be understood as a discrete graph linked to the main chain 252 via a two-way peg. In this case, the DAG acts as the side chain 652, where the machine writing the transaction on the main chain 252 must send its funds to an output address. Once the tokens are in the output address, they are locked-in. This means the machine can no longer use the tokens. To ensure increased security, communication is sent via the main chain 252 and the side chain 652, and a waiting period is allowed after the machine's tokens are moved to the output address. Once the waiting period ends, the tokens are released to the side chain 652. The machine can then spend the tokens on the side chain 652. When moving from the side chain 652 to the main chain 252, the machine sends the tokens from the side chain 652 to the output address where they were locked. After the waiting period ends, the same number of tokens are transferred to the main chain 252. This serves as a two-way synchronization between the two hybrid distributed ledgers, the first implemented by the main chain 252 and the second by the side chain 652. The side chain 652 offers many benefits: (1) The DAG side chain 652 is independent of the firewall-protected main chain 252 and is responsible for its own security without posing a significant risk to the integrity of the main chain 252. (2) The DAG is known for the scalability of its parallel transactions by its very nature. The DAG is a layer-2 extension that allows transactions to occur outside of the main chain 252, which can be further extended via IoT. Thus, the pressure is taken off the main chain 252 and allows the main chain 252 to further accelerate transactions. (3) Supports two-way peg assets with interoperability (assets issued by the side chain 652 return to the main chain 252 assets at a determined exchange rate). (4) Includes the option of a federated side chain to add nodes between the main chain 252 and the side chain 652 via consensus.

[0069] Figure 8 A schematic diagram of a multi-access edge computing node cluster 800 including a number of multi-access edge computing nodes 802M according to the present invention is provided, where each computing node 802M is configured to support data block deployment (deployed on both the main chain 252 and the side chain 652 shown in Figure 6 , 7 ), to allow for various workloads, orchestration, and governance driven by policies. Each multi-access edge computing node 802M has an automation platform block 820, which serves as an operational interface for communicating with the distributed ledger, such as checking its status and executing instructions. An overview of the functions provided by the automation platform 820 is described below.

[0070] Smart contracts exist as one or more decentralized applications or distributed ledger applications running on the application layer 804. These smart contracts are written in code that complies with the rules of the application interface layer 806 so that the smart contracts can work with the distributed ledger provided by the deployed data blocks. Examples of smart contracts include applications that enable IoT services to utilize the blockchain deployed by the multi-access edge computing nodes 802M, and these services include, but are not limited to, augmented reality (AR), virtual reality (VR), or facial recognition.

[0071] The management block 808 includes a smart policy engine block 810, a smart contract block 812, and a virtual machine (VM) block 814. Refer Figure 6 and 7 , the smart policy engine block 810 determines which of the protocol 200 of the first layer and the protocol 650 of the second layer is used to process the smart contract. When the smart contract uses encryption to shield sensitive data (such as the personal details of the parties executing the smart contract and the digital wallets used to pay them), the smart policy engine block 810 also processes the output of the zero-knowledge protocols supported by each multi-access edge computing node 802M, and these protocols are described in more detail in Figure 10 Therefore, the smart policy engine block 810 helps manage the data blocks generated from the transactions implemented by the smart contracts written to the chained data blocks. In one embodiment, where access to a dedicated processor is available (described later in Figure 10 ), the smart policy engine block 810 also distributes the computing load between the dedicated processor and the inventory processors of the multi-access edge computing nodes 802M. The virtual machine block 814 is used to provide a runtime environment to provide a system with data manipulation rules that need to be followed to create compliant smart contracts.

[0072] The storage block 816 manages recording smart contract transactions into the data blocks in the distributed ledger (of the main chain 252 or the side chain 652). The storage block 816 also manages the peripheral data associated with the smart contract transactions, such as, but not limited to, the identities of the IoT devices that are parties to the smart contract transactions and the data generated by the decentralized applications running on the application layer 804. The data blocks are stored according to any peer-to-peer (Peer to Peer) distributed file system standard, such as the Inter Planetary File System (IPFS) and 's "Ceph". Such standards support the hybrid protocols described in Figure 6 and 7 .

[0073] The messaging block 818 is used for data communication or input instructions.

[0074] Figure 9A schematic diagram of multi-access edge computing node clusters 902, 904, and 906 is provided, with each node cluster residing in different regions A, B, and C. The distributed ledger DLT 908 hosted by clusters 902, 904, and 906 according to the present invention is schematically shown in the figure.

[0075] Figure 9 An ecosystem of interconnected multi-access edge computing node clusters 902, 904, and 906 in a federated network using container orchestration 910 is shown. More specifically, each node of clusters 902, 904, and 906 runs a container image, which is a lightweight, independent, executable software package that includes everything needed to run a distributed ledger: code, runtime, system tools, system libraries, and settings. Container orchestration 910 provides, schedules, and manages containers at scale for decentralized applications / distributed ledger applications (DApps) residing in these containers.

[0076] DApps services are orchestrated between multi-access edge computing node clusters 902, 904, and 906. The federated container is where these containers are managed in the cluster, and thus there is a federated container orchestration 912 because these multi-access edge computing node clusters 902, 904, and 906 can belong to different operator networks. The federated container orchestration 912 can be implemented through open-source operating system-level virtualization.

[0077] Federated container orchestration 912 allows for the consistent deployment of DApps across each multi-access edge computing node in clusters 902, 904, and 906, thereby allowing for the efficient and reliable execution of DApps. Extrapolating, federated container orchestration 912 facilitates the deployment of a set of distributed ledger applications across the multi-access edge computing node clusters 902, 904, and 906, where each application is configured to interface with the distributed ledger DLT 908. That is, the set of distributed ledger applications has been encoded to work on the distributed ledger DLT 908 and output data in a compatible format to be included in the chained data blocks shared by the distributed ledger DLT 908. As previously mentioned, the distributed ledger applications are encoded programs to support smart contracts written into the distributed ledger DLT 908. Under federated container orchestration 912, the set of distributed ledger applications is encoded to comply with the rules imposed in the jurisdictions to which each multi-access edge computing node cluster 902, 904, and 906 belongs. That is, if a contract is signed between a party in zone A and a party in zone B, the regulatory requirements of both zone A and zone B will be automatically met because the distributed ledger application supporting the execution of the contract in zone A complies with the regulatory requirements of zone A, and the distributed ledger application supporting the execution of the contract in zone B complies with the regulatory requirements of zone B. Thus, a solution for implementing cross-border transactions is achieved. Additionally, each of the clusters 902, 904, and 906 shares service discovery so that backend resources can be accessed from any other cluster. If a container fails, another container will be automatically created.

[0078] It should be understood that the various functions described so far (such as data block generation, smart contract execution, and smart policy engine management) are controlled by the central processing unit (CPU) of the multi-access edge computing node. The CPU is formed by one or more core processors that have this functionality after software installation, which will write instructions for performing the necessary arithmetic and logical operations to execute the functions into the registers of the operating system of the multi-access edge computing node. The term "stock processor" refers to such a CPU that is part of the standard technical specification of the multi-access edge computing node.

[0079] Figure 10 Shown in the implementation of the distributed ledger DLT 1008 by Figure 1Non-exhaustive schematic illustration of functions 1004 executed by the inventory processors of each of the multi-access edge computing nodes 102M, 104M, and 106M. Also shown is a schematic illustration of a dedicated processor 1040 designed to share the computational load of the inventory processors of the multi-access edge computing nodes 102M, 104M, and 106M to execute these functions. In contrast to the inventory processors, the dedicated processor 1040 is a processor specifically designed to share the computationally intensive workload of the inventory processors encountered during data block deployment. Thus, the architecture of the dedicated processor 1040 is equipped with logical partitions for such data block deployment.

[0080] Functions 1004 include determination of a consensus mechanism 1006, transaction shielding 1008, node management 1010, and quantum key generator 1012.

[0081] Reference Figure 6 and 7 , the consensus mechanism 1006 refers to the offloaded computational workload (encryption / decryption) that occurs when executing the consensus mechanisms described in Figure 2 , 6 and 7.

[0082] Transaction shielding 1008 refers to solving privacy and security issues in the distributed ledger DLT 1008 by using zero-knowledge protocols. ZKP allows entities to store only the proof of transactions on the nodes. They keep the sensitive data to themselves while still maintaining confidence in the provenance of the relevant records.

[0083] 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 other than the fact that the particular statement is true. A zero-knowledge proof (ZKP) verifies the truth of something without revealing how the truth is known or sharing the content of this truth with the verifier. The principle is based on an algorithm that takes some data as input and returns "true" or "false". A ZKP must meet three criteria:

[0084] 1. Completeness: If the statement is true, an honest verifier (i.e., someone who follows the protocol correctly) will be convinced of this fact by an honest prover.

[0085] 2. Soundness: If the statement is false, then no cheating prover can convince an honest verifier that it is true, except for some small probability events.

[0086] 3. Zero - knowledge: If the statement is valid, no verifier can learn anything other than the fact that the statement is true. In other words, just knowing the statement (not the secret) is sufficient to imagine a scenario that shows the prover knows the secret. This is formalized by showing that for every verifier there is some simulator that is given only the statement to be proven (and has no access to the prover), and the simulator can produce a transcript that "looks like" the interaction between an honest prover and the verifier.

[0087] The first two criteria are properties of more general interactive proof systems. The third criterion is what makes the proof zero - knowledge.

[0088] When the multi - access edge computing nodes 102M, 104M, and 106M detect that the current transaction to be recorded as a new data block in the distributed ledger DLT1008 contains masked data (e.g., the identities of the parties to a smart contract transaction; details of the digital wallets used to pay for a smart contract transaction; messages or instruction sets between two or more parties on the distributed ledger) to authenticate the masked data, a zero - knowledge protocol that complies with the above principles is imposed by the transaction masking 1008 function. The authentication of the masked data reduces the arithmetic operations where the output of a logical level "1" or "0" determines whether the content of the masked data is known. The output of the zero - knowledge protocol determines whether the current transaction can be verified as valid (i.e., a new data block can be recorded in the blockchain).

[0089] When either or both of the storage processors and the dedicated processors 1040 in the multi - access edge computing nodes 102M, 104M, and 106M detect the presence of masked data, these processors identify statements within the current transaction that are designed to prove the truthfulness of whether the content of the masked data is known, where the masked data is masked or encrypted. These statements serve as a means to prove that the transaction is legitimate because the masked data is masked and cannot be analyzed to make such a determination. The identified statements can be formalized according to the principles of zero - knowledge proofs on which the algorithm is based. The algorithm takes specific data as input and returns whether the identified statement is "true" or "false". The processors evaluate the truthfulness of the identified statements, and if it is determined that the content of the masked data is known, the current masked transaction is authenticated. Although absolute certainty is not guaranteed, the statements are formalized such that a positive result reflects a high probability that the current transaction is legitimate, which in turn allows the current transaction to be recorded as a new data block, as Figure 2 、 6 and shown in 7.

[0090] When evaluating the truthfulness of the identified statements, the processors of the multi-access edge computing nodes 102M, 104M, and 106M are also configured to determine that the identified statements are evaluated as true by each of a set of external multi-access edge computing nodes. That is, taking the perspective of the multi-access edge computing node 102M as an example, each of the multi-access edge computing nodes 104M and 106M also reaches a consensus that they are also evaluating the truthfulness of the one or more identified statements. The consensus may follow Figure 2 the method described in

[0091] The first method is based on zero-knowledge Succinct Non-Interactive Argument of Knowledge (zk-SNARK) to establish a statement for the validity of the current transaction. This is a protocol that creates a framework in which the current transaction - submitted by a multi-access edge computing node (such as 102M, see Figure 1 ) called the prover for verification - can quickly convince other multi-access edge computing nodes (such as 104M and 106M, see Figure 2 ) - called the verifiers - that the prover knows a secret without revealing any of the secret.

[0092] This protocol implements a circuit with inputs of 0 or 1 and outputs of 0 or 1. The prover knows the string (0, 1,..., 1) that will result in a 0 output. The secret of the prover is this string, which in one implementation is based on the details of the masked data and in another implementation can be arbitrarily generated. To convince the verifier that the prover knows the string with an output of 0, the prover provides the verifier with a proof π. The verifier checks this proof. If the proof is correct, the verifier can determine that the prover knows the correct string.

[0093] The Quadratic Arithmetic Program (QAP) provides the prover with a tool for constructing the proof π to prove that the prover knows a valid assignment (a 1 ,..., a N ) ∈ F N for a given arithmetic circuit C. A QAP, Q(C):=(A→, B→, C→, Z), provides the following three sets of polynomials:

[0094]

[0095] where the coefficients in F and the target polynomial Z(z) ∈ F[z] are such that the polynomial Z(z) divides the following polynomial:

[0096]

[0097] if and only if (a 1 ,..., a N ) is a valid assignment for circuit C. The prover constructs P(z) for its proof π, and the verifier can check the property that P(z) is divisible by Z(z).

[0098] Another approach uses a one-time trusted setup to generate a private / public key pair, which is used to generate statements for establishing the validity of the current transaction. The private part is compromised, and another key pair is generated from the public part, resulting in a proof key and a verification key. The proof key and the verification key are distributed to provide a common reference shared between the prover and the verifier. The current transaction to be recorded in the distributed ledger of the multi-access edge computing nodes 102M, 104M, and 106M contains computations created by the distributed prover key, e.g., by generating a proof using a given public input and the prover key. The processors of the multi-access edge computing nodes 102M, 104M, and 106M are configured to obtain the distributed verification key corresponding to the distributed prover key when implementing their role as "verifiers". The processors evaluate the computations using the distributed verification key, and in response to the evaluation of the computations that produce the correct output, allow the verification to be valid (i.e., for the new data block to be recorded).

[0099] A second method for evaluating the truthfulness of the statements used to determine the validity of the current transaction uses an interactive approach.

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

[0101]

[0102] This definition states that the interactive proof system <P, V> is zero-knowledge if for any verifier V* there exists an efficient simulator S, where for any given input, the simulator S can essentially produce a transcript of the conversation that takes place between P and V*. Thus, conversing with P cannot teach V* something that could not be computed before. The string z in this definition plays the role of "prior knowledge" (including the random coins of V*); V* cannot use any prior knowledge string z to extract information from its conversation with P, because the requirement is that if S is also given this prior knowledge, it can reproduce the conversation between V* and P as before.

[0103] In the interaction method, the processors of the multi-access edge computing nodes 102M, 104M, and 106M are configured to iterate the identified statements through at least one test; and when most of the iterations produce consistent results, conclude that these statements are correct.

[0104] Now turning to node management 1010, this refers to monitoring the operation of the dedicated chip 1040, such as its registers 1018A, RAM 1018B, and QKD (Quantum Key Distribution) register 1018C. Register 1018A holds the unique ID of the dedicated chip 1040. This ID is written into register 1018A during manufacturing. The same ID is protected and stored on the DLT 1008. More than one register 1018A can be added to the dedicated chip 1040.

[0105] RAM 1018B provides a cache for the dedicated chip 1040. The QKD register 1018C stores encryption keys used by the dedicated chip 1040, the inventory processor, or both.

[0106] Quantum key generation 1012 is responsible for selecting a zero-knowledge protocol from the QKD register 1018C for use when analyzing transactions with masked data.

[0107] When a transaction is to be recorded in the distributed ledger DLT 1008, the required calculations can be obtained from both the processors of the multi-access edge computing nodes 102M, 104M, and 106M and the dedicated processor 1040. The dedicated processor 1040 is designed to share the computational load of the inventory processors of the multi-access edge computing nodes 102M, 104M, and 106M by being divided into logic blocks 1014, 1016, and 1018. Each block has electronic devices designed to share the execution of one of the corresponding functions of the processor through an appropriately connected combination of logic gate circuits. In an implementation of the ASIC (Application-Specific Integrated Circuit) 1020, a semiconductor substrate is fabricated using logic gate circuits from a component library according to a circuit schematic specifically designed to support the distributed ledger DLT 1008.

[0108] The encryption / decryption accelerator block 1014 shares the computational load with the consensus mechanism 1006. The ZKP (Zero-Knowledge Protocol) accelerator block 1016 shares the computational load with the transaction masking 1008. The OID register / Secure RAM / QKD register block provides relevant data for the node management 1010 and the QKD generator 1012. Communication between the dedicated processor 1040 and the processors of the multi-access edge computing nodes 102M, 104M, and 106M is carried out through the high-speed bus 1022. The high-speed bus 1022 can operate on any one or more of the following connection protocols: USB2.0, 3.x, PCIe, SATA, NVMe.

[0109] Figure 11 shows Figure 10 the layout of the dedicated processor 1040. The dedicated processor 1040 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 Figure 1 any of the multi-access edge computing nodes 102M, 104M, and 106M and their associated base stations 102, 104, and 106 described in Figure 10 . The dedicated processor 1040 can be provided as a removable dongle and installed on a printed circuit board with an inventory processor on which the multi-access edge computing nodes 102M, 104M, and 106M are installed or integrated into a motherboard or electronic circuit board via the high-speed bus 1022 mentioned in

[0110] Within the board 1106 on which the dedicated processor 1040 is installed, the dedicated processor 1040 has electronics with logical partitions divided over a secure area 1102 and a non-secure area 1104 at the chip boundary 1105. These electronics include many basic logic gate circuits configured as AND, OR, XOR, NOT, NAND, NOR, and XNOR, which are appropriately connected to implement the functions required for each logical partition.

[0111] The board 1106 has board-level devices 1108, a power supply 1110 for powering the components of the dedicated processor 1040, and an external clock 1112.

[0112] The non-secure area 1104 has its own power section 1116, a general-purpose interface 1114, a clock 1118, and system services 1120. Communication between the non-secure area 1104 and the secure area 1102 takes place over an APB (Advanced Peripheral Bus) 1122.

[0113] The components of the secure area 1102 are as follows: a processor core 1124, on-chip RAM 1126, on-chip memory 1128, direct memory access (DMA) modules 1134 and 1136, an error-correcting code memory 1132 (for correcting internal data corruption), a secure boot ROM 1138, a true random number generator (TRNG) 1140, a one-time programmable (OTP) section 1142, and encryption modules: SHA-2 1144, SHA-3 1146; ZKP 1148; RSA 1150, and AES 1152. The OTP section provides one or more areas, where each area can be used to store data such as the serial number of a dedicated chip having interconnect fuses that will subsequently be blown.

[0114] The processor core 1124 communicates with the encryption module via the Advanced High-Performance Bus (AHB) 1130. The SHA-2 1144 and SHA-3 1146 modules provide secure hash algorithms for the data blocks in the blockchain described in Figure 2 and 6 Blockchain data blocks as described in 7. As Figure 10 shown, the ZKP 1148 module provides a zero-knowledge protocol to handle transactions with masked data. The RSA 1150 module provides a Rivest-Shamir-Adleman (RSA)-compatible algorithm, and the Advanced Encryption Standard algorithm provided by the AES 1152 module can be used when processing transactions for recording in the blockchain. The processor core 1124 also uses the AHB 1130 to communicate with external components (such as the storage processor of a multi-access edge computing node) via the high-speed interface 1154, or to communicate with the non-secure area 1104 via the bridge 1156.

[0115] Refer to Figure 10 , one or more components of the secure area 1102 are called to facilitate the required calculations by the inventory processor to achieve the functionality 1004. For example, one or more components of the secure area 1102 are activated to provide an accounting management partition, which is configured to share the computational load of the inventory processor of the multi-access edge computing node to include new data blocks for recording current transactions regarding goods or services into the chained data blocks stored in at least one memory of the multi-access edge computing node, where the dedicated processor 1040 is installed on the multi-access edge computing node. The new data block is recorded in response to a signature that is generated by processing the data of the current transaction using the encoded data of past transactions stored in the chained data blocks and verified as valid by a set of trusted external multi-access edge computing nodes. The accounting management partition may include the processor core 1124, which sends instructions to the SHA-2 1144, SHA-3 1146, RSA 1150, AES 1152, and ECC 1132 modules to perform the hashing required for recording the new data block described in Figure 2 .

[0116] Figure 6 and 7It is described that the distributed ledger can record new data blocks into the main chain 252 or the side chain 652, depending on the processing power required to record the new data block. In order to allow the implementation of the side chain 652, the accounting management partition can also be configured to share the computing load of the inventory processor of the multi-access edge computing node to: lock the asset in at least one data block of the main chain 252. Then, the dedicated processor 1040 records the transaction that has been determined to be based on the locked asset into one or more data blocks of the side chain 652; and uses the locked asset to assist in linking the side chain 652 to the data block of the main chain 252.

[0117] One or more components of the secure area 1102 are activated to provide a shielded transaction verification partition that is configured to offload the computational load of inventory processors of multi-access edge computing nodes to process transactions with shielded data, which refers to data that should be kept confidential and not shared.

[0118] In the event that the shielded transaction verification partition detects a transaction with such shielded data, the shielded transaction verification partition uses a zero-knowledge proof that authenticates the shielded data by applying an arithmetic operation that reduces to an output of a logic level "1" or "0" to determine whether the content of the shielded data is known. The output of the zero-knowledge protocol determines whether the current transaction can be validly verified (i.e., a new data block can be recorded to the blockchain). The shielded transaction verification partition seeks to locate statements that prove the authenticity of whether the content of the shielded data is known, where arithmetic operations are applied to these statements while the shielded data is masked or encrypted. The identified statements can be normalized according to the principles of zero-knowledge proofs. If the evaluation of the identified statements indicates that the content of the shielded data is indeed known, the shielded data is authenticated and the current transaction is allowed to be recorded as a new data block, such as Figure 2 , Figure 6 and Figure 7 shown.

[0119] When evaluating the authenticity of the identified statement, the shielded transaction verification partition can be further configured to determine that the identified statement has been evaluated as true by each of a set of external multi-access edge computing nodes. That is, each multi-access edge computing node also reaches a consensus that each multi-access edge computing node is also evaluating the authenticity of one or more identified statements.

[0120] A method for authenticating statements of hidden data is based on zero-knowledge succinct non-interactive arguments of knowledge (zk-SNARK). For example, a one-time trusted setup for generating a private / public key pair is used to generate statements for establishing the validity of the current transaction. The private part is compromised, and another key pair is generated from the public part, resulting in a proof key and a verification key. The proof key and the verification key are distributed to provide a shared common reference. The current transaction to be recorded in the distributed ledger contains computations created from the distributed proof key, for example, by using a given public input and the proof key to generate a proof. The shielded transaction verification partition is configured to obtain the distributed verification key corresponding to the distributed proof key. The shielded transaction verification partition evaluates the computations using the distributed verification key and allows the valid verification (i.e., for the new data block to be recorded) in response to the evaluation of the computations yielding a correct output.

[0121] Another method evaluates the authenticity of statements for authenticating shielded data through an interactive method. The shielded transaction verification partition may also be configured to iterate the identified statements through at least one test; and conclude that the statements are correct when most of the iterations yield consistent results.

[0122] In the case where the shielded transaction verification partition detects that the current transaction contains data that needs to be shielded, the shielded transaction verification partition shields such data. Then, the shielded transaction verification partition formulates statements for proving whether the content of the shielded data is known and masks the shielded data.

[0123] Figure 12 A process is provided that demonstrates how the intelligent policy engine 1210 (also Figure 8 the reference numeral 810) implements the distributed ledger as shown in Figure 2 , Figure 6 and Figure 7 , where the intelligent policy engine 1210 runs on the inventory processor of a multi-access edge computing node with a Figure 11 dedicated processor 1040.

[0124] In step 0, a transaction occurs, which can be a simple nano transaction (Tx) to be recorded on the side chain (refer to Figure 6 and 7 ) or a transaction with a smart contract (SC) to be recorded on the main chain. The transaction may or may not require data shielding and its associated zero-knowledge protocol.

[0125] In step 1, the intelligent policy engine 1210 acts as a communication bridge between the distributed ledger 1212 and the dedicated processor 1040. The intelligent policy engine 1210 will collect the required tasks and the number of zero-knowledge proofs (ZKP) from the distributed ledger 1212.

[0126] In step 2, the intelligent policy engine 1210 organizes tasks in a pool and assigns ZKP transaction priorities. The intelligent policy engine 1210 can split the pool into a "large pool", "medium pool", or "small pool"

[0127] In step 3, according to the policy defined by the intelligent policy engine 1210, the priority setting is completed, and the instruction set is sent to the dedicated processor 1040 one by one.

[0128] In step 4, the dedicated processor 1040 includes an internal task mixer, which is responsible for issuing jobs to multiple embedded accelerators (acc_1, acc_2_n) within the dedicated processor 1040. The calculation is completed within a predefined window. The combiner will combine all the calculation results in batches.

[0129] In step 5, the dedicated processor 1040 sends the result back to the intelligent policy engine 1210.

[0130] In step 6, the intelligent policy engine 1210 will complete the ZKP mask package, which is passed to the distributed ledger 1212 for valid verification.

[0131] Figure 13 is a schematic diagram of a system including the distributed ledger 1008, which is implemented by the processors of the multi-access edge computing nodes 102M and 104M of Figure 1 and shares the computing load with the dedicated processor 1040 of Figure 11

[0132] In the case where the dedicated processor 1040 is connected to the inventory processors of the multi-access edge computing nodes 102M and 104M, all functionality is enhanced. The protocols 200 and 650 for recording the transactions of usage instances 1324 and 1326 into the distributed ledger 1008 are executed faster. The usage instance 1324 shows a heavyweight smart contract transaction through layer 1 (reference number 200), and the usage instance 1326 is a lightweight nano transaction through layer 2 (reference number 650), which accelerate the performance and consensus of the distributed ledger 1008 supported by the dedicated processor 1040.

[0133] The provision of the dedicated processor 1040 results in an overall lower latency, improved performance, and support for privacy encryption.

[0134] Figure 14 is a schematic diagram explaining how to select the witness multi-access edge computing node 1406.

[0135] ​In a network 1400 that includes multi-access edge computing nodes that utilize a distributed ledger, stakeholders 1402 refer to machines that hold utility tokens. These stakeholders 1402 continuously monitor the multi-access edge computing nodes for optimal performance and vote them as trustworthy. The trustworthy multi-access edge computing nodes become witnesses 1404, which are permitted to update the distributed ledger with data from new transactions. A consensus must be reached among a certain percentage of the witnesses 1404 (e.g., 66 or 67 of them). Representatives 1406 are composed of a consortium of mobile network operators and have the right to propose changes to the network 1400 through the voting of stakeholders 1402.

[0136] In this application, unless otherwise specified, the terms "comprising," "including," and their grammatical variants are intended to denote an "open" or "inclusive" language such that they include the recited elements and also permit the inclusion of additional, unspecified elements. It should also be understood that the terms "information" and "data" are used interchangeably, especially when recording transactions in a distributed ledger.

[0137] Although the invention has been described with reference to exemplary embodiments, those skilled in the art will understand that various changes can be made and elements thereof can be replaced with equivalents without departing from the spirit and scope of the invention. Additionally, modifications can be made to adapt the teachings of the invention to specific situations and materials without departing from the essential scope of the invention. Accordingly, the invention is not limited to the specific examples disclosed in this specification but includes all embodiments that fall within the scope of the appended claims.

[0138] References: 1.

[0140] https: / / www.forbes.com / sites / louiscolumbus / 2017 / 12 / 10 / 2017-roundup- of-internet-of-things-forecasts / #40aa818e1480

Claims

1. A multi-access edge computing node is positioned to utilize the radio access network infrastructure of a base station of a mobile network operator for cellular communication, the cellular communication including 4G and 5G frequency bands, the multi-access edge computing node comprises: at least one memory for storing chained data blocks, wherein each data block is encoded with data of past transactions regarding goods or services; at least one inventory processor; and a dedicated processor configured to share the computing load of the inventory processor, the dedicated processor having electronics divided into logical partitions, the logical partitions including a shielded transaction verification partition configured to process transactions containing shielded data using zero-knowledge proofs, the zero-knowledge proofs authenticating the shielded data while the shielded data is masked; wherein, the at least one inventory processor is configured with the following functions: include a new data block for recording a current transaction regarding goods or services into the chained data blocks in response to a signature generated by processing data of the current transaction with encoded data of past transactions stored in the chained data blocks and verified valid by an external group of multi-access edge computing nodes, wherein the multi-access edge computing node and the external group of multi-access edge computing nodes are trusted and communicate through a common channel, and wherein data regarding transactions is received through a cellular connection provided by the base station; and guide the shielded transaction verification partition of the dedicated processor to process transactions containing the shielded data using the zero-knowledge proofs, wherein the output of the zero-knowledge proofs determines whether the transaction is recorded as a new data block.

2. The multi-access edge computing node according to claim 1, wherein the data blocks belong to a main chain, and wherein the inventory processor is further configured with the following functions: lock assets in at least one data block of the main chain; record transactions determined to be based on the locked assets into one or more data blocks of a side chain; and link the side chain to the data block of the main chain with the locked assets.

3. The multi-access edge computing node according to claim 2, wherein, the inventory processor is further configured with the following functions: when updating the main chain of the expenditure of the locked assets generated by transactions recorded in the side chain, write the transactions recorded in the data blocks of the side chain into one or more data blocks of the main chain.

4. The multi-access edge computing node according to claim 2 or 3, wherein, the inventory processor is further configured with the following functions provided to a policy engine: evaluate a current transaction for recording under the main chain or the side chain in the case of executing the current transaction; and record the current transaction in the main chain or the side chain in response to the above evaluation.

5. The multi-access edge computing node according to claim 2 or 3, wherein, the inventory processor is further configured with the following functions: when determining that the current transaction contains shielded data: analyze the current transaction using a zero-knowledge protocol configured to verify the above shielded data; and Process the output of the zero-knowledge protocol, where the output determines whether the current transaction can continue with verification.

6. The multi-access edge computing node according to claim 5, wherein the zero-knowledge protocol further configures the inventory processor with the following functions: Identify that there are statements in the current transaction, and the statements are intended to prove the authenticity of whether the content of the masked data in the masked data is known; Evaluate the identified statements; and In response to the evaluation proving that the masked data is known, allow the verification to continue effectively.

7. The multi-access edge computing node according to claim 6, wherein, the inventory processor is further configured with the following functions: Determine that each of the external multi-access edge computing node groups has reached the same evaluation of the identified statements.

8. The multi-access edge computing node according to claim 6, wherein, the statement is based on calculations generated from distributed proof keys, and the inventory processor is further configured with the following functions: Obtain the distributed verification key corresponding to the distributed proof key; Evaluate the calculation using the distributed verification key; and In response to the evaluation of the calculation generating a correct output, allow the verification to continue effectively.

9. The multi-access edge computing node according to claim 6, wherein in order to evaluate the authenticity of the identified statement, the inventory processor is further configured with the following functions: Iteratively test the identified statement through at least one test; and When most of the iterations produce consistent results, conclude that the statement is true.

10. The multi-access edge computing node according to claim 5, wherein the inventory processor is further configured with the following functions provided to the policy engine: The policy engine is configured to decide whether to record the current transaction in the main chain or the side chain and process the output of the zero-knowledge protocol.

11. The multi-access edge computing node according to claim 2 or 3, wherein the common channel is on the path used by the base station, the base station supports communication between the multi-access edge computing node and a base station with a cellular coverage area, and each of the external multi-access edge computing node groups is located in the cellular coverage area.

12. The multi-access edge computing node according to claim 10, wherein the inventory processor is further configured with the following functions: In response to receiving an accompanying security certificate for authenticating the chained data block, copy the chained data block from the external multi-access edge computing node group to the at least one memory.

13. The multi-access edge computing node according to claim 2 or 3, wherein each data block in the chained data block includes a hash of the data in the previous data block.

14. The multi-access edge computing node according to claim 1, wherein the transactions stored in the chained data block include data related to the execution of smart contracts.

15. The multi-access edge computing node according to claim 14, wherein the data related to the execution of the smart contract includes any one or more of the following items: purchase and sales contracts; debit and credit of digital wallets; tracking of resources in the supply chain; streaming of media content; power consumption management; and monitoring of path traffic conditions.

16. The multi-access edge computing node according to claim 2 or 3, wherein the dedicated processor is provided as a removable dongle, mounted on a printed circuit board or integrated into a circuit board on which the inventory processor is mounted.

17. The multi-access edge computing node according to claim 2 or 3, wherein the multi-access edge computing node is located near the base station.

18. The multi-access edge computing node according to claim 2 or 3, wherein the data communication regarding the data block including the new data occurs within a 4G or 5G frequency band.

19. The multi-access edge computing node according to claim 2 or 3, wherein the inventory processor is further configured to deploy an encoded distributed ledger application to support the execution of cross-border smart contracts.

20. The multi-access edge computing node according to claim 1, wherein, the logical partition of the dedicated processor further includes: an accounting management partition, configured to share the computing load of the inventory processor of the multi-access edge computing node to include new data blocks, to record the current transaction regarding goods or services into a chained data block stored in at least one memory of the multi-access edge computing node on which the dedicated processor is mounted, in response to a signature, the signature being generated by processing the data of the current transaction with the encoded data of past transactions stored in the chained data block and verified as valid by a trusted group of external multi-access edge computing nodes; and wherein, the masked transaction verification partition is further configured to: generate masked data including the current transaction data determined to be masked; and formulate a statement aimed at proving the authenticity of whether the masked data content in the masked masked data is known.

21. The multi-access edge computing node according to claim 20, wherein the accounting management partition of the dedicated processor is further configured to share the computing load of the inventory processor of the multi-access edge computing node so as to: lock assets in at least one data block of the main chain; record the transactions determined to be based on the locked assets into one or more data blocks of the side chain; and link the side chain to the data block of the main chain with the locked assets.

Images