Abstract: A system supports asset transfers among blockchains of differing distributed ledger technologies using interop circuitry. The interop circuitry may receive asset permissions from origin and target participant circuitry. The asset permissions may support transfer of an asset from an origin blockchain to a target blockchain. The interop circuitry, acting on behalf of the origin and target participant circuitry, locks an asset on the origin blockchain. Then the interop circuitry creates the asset on the target blockchain. The locking of the asset on the origin blockchain may prevent a double-expend opportunity, where the asset can be redeemed on the origin blockchain and on the target blockchain.

Abstract: A system includes a display control prime located within a central-zone in communication with a provisioned agent operating on an edge-zone device. The display control prime may implement prime-blind open-loop pixel-state control on the edge-zone device by executing pixel-state commands via the provisioned agent. The provisioned agent, operating within the edge-zone, may have access to un-sanitized data, which may be unavailable to the display control prime in the central-zone. The display control prime may provide conditional pixel-state commands via a pixel-state control parameter matrix. The provisioned agent may identify an operative pixel-state command from among the conditional pixel-state commands based on the un-sanitized data to which the display control prime is blind.

Abstract: Systems and methods for active state synchronization between distributed ledger technology (DLT) platforms are provided. A system may store an origin blockchain compliant with an origin DLT. The system may further store a target blockchain compliant with a target DLT. The target DLT may be different from the origin DLT. The system may include a DLT object synchronizer with access to the origin blockchain and the target blockchain. The DLT object synchronizer may receive, from an exchange node, a request to synchronize an origin instance of a DLT object between the origin blockchain and the target blockchain. The DLT object synchronizer may select a target instance of the DLT object on the target blockchain. The DLT object synchronizer may format origin data from the origin instance for compliance with the target DLT. The DLT object synchronizer may synchronize the origin instance and the target instance.

Abstract: A participant node of a distributed ledger network may identify a distributed federated learning (DFL) smart contract stored on a blockchain. The DFL smart contract may include an aggregation sequence. The aggregation sequence may include an ordered sequence of participant node identifiers. The participant node may generate a trained model by training a global model with training data. The participant node may detect, on the blockchain, a first transition token indicative of a first model previously aggregated by another participant node. The participant node may receive the first model. The participant node may aggregate the first model with the trained model to generate a second model. The participant node may store, on the blockchain, a second transition token indicative of the second model. A successor node identified in the aggregation sequence may further aggregate the second model with an additional model in response to detection of the second transition token.

Abstract: In some examples, distributed ledger technology and artificial intelligence-based energy trading may include ascertaining energy data that includes historical weather data for a plurality of units, future climate forecast data, household behavioral energy data, and distributed ledger technology energy marketplace data. Based on a specified time interval, a specified future time duration may be divided to generate a plurality of specified divided future time durations to determine a price of energy. A trading recommendation may be generated for a time during the specified future time duration to buy the energy from a distributed ledger technology energy marketplace, and/or another time during the specified future time duration to sell the energy to the distributed ledger technology energy marketplace. Further, instructions to implement the recommendation may be generated to buy the energy and/or sell the energy.

Abstract: A system may provide a smart contract interface for blockchain interoperability. The system receive selection parameters indicative of a furnisher blockchain and a receiver blockchain. The system may obtain, based on the selection parameters, furnisher synchronization logic and receiver synchronization logic. The furnisher synchronization logic may include instructions to lock token data on the furnisher blockchain. The receiver synchronization logic may include instructions to commit token data to the receiver blockchain. The system may generate an interoperability smart contract comprising the furnisher synchronization logic and the receiver synchronization logic. The system may deploy the interoperability smart contract to a furnisher blockchain and the receiver blockchain.

Abstract: In some implementations, a system may generate information that identifies a passphrase to be used as a biometric input. The system may receive a voice input of a user speaking the passphrase. The system may generate one or more cryptographic keys based on the voice input. The system may generate a digital identifier based on the one or more cryptographic keys. The system may generate one or more biometric templates for the user. The system may encrypt the one or more biometric templates using the one or more cryptographic keys and to generate one or more encrypted biometric templates. The system may store in a secure storage associated with the user, at least one of the digital identifier, a public key of the one or more cryptographic keys, a phone number associated with the user, or the one or more encrypted biometric templates. Numerous other aspects are provided.

Abstract: A system may receive a request to perform a token exchange between a first account and a second account. A selected token for the token exchange may be associated with the first account. A hash of the selected token may be stored on a furnisher blockchain of a first distributed ledger. The system may generate a new token and a hash of the new token. The system may generate a shielded exchange instruction, the shielded exchange instruction comprising the hash of the new token and a zero-knowledge proof, wherein the zero-knowledge proof is indicative of the selected token being associated with the first account. The system may submit the shielded exchange instruction to a distributed ledger technology platform to cause execution of a furnisher smart contract and a receiver smart contract. Each of the smart contracts are configured to separately verify the zero-knowledge proof and update corresponding blockchains to consummate and record the token exchange.

Abstract: A commodity-measuring device for autonomously selecting a commodity supplier among a plurality of commodity suppliers being specified within a blockchain distributed database is provided. A microcontroller unit is configured to provide commodity consumption data to the transaction manager. A storage is configured to store a private key, and a communication module is configured to retrieve a commodity supplier file stored in the blockchain distributed database, and the commodity supplier file includes parameters of a commodity supplier and a program. A transaction manager is configured to determine autonomously, based on the commodity consumption data and parameters in the commodity supplier file, whether to select the commodity supplier; and if the determination is positive, the transaction manager is configured to, using the private key, send a transaction to the blockchain distributed database calling a function in the program to associate the commodity supplier file with the identifier.

Abstract: A master oracle may receive an oracle network identifier for an oracle network. The master oracle may receive a plurality of data messages respectively generated by the oracles. The master oracle may verify, based on respective public keys for the oracles, that each of the data messages are digitally signed by a different corresponding one of the oracles. The master oracle may aggregate the data messages into an aggregated data message. The master oracle may digitally sign the aggregated data message with a private key and public key pair. The master oracle may transmit the aggregated data message to a participant node of a distributed ledger network. A smart contract stored on a blockchain may verify the aggregated data. After receiving and verifying the aggregated data message the smart contract may execute to perform operations based on the aggregated data message.

Abstract: A system includes a display control prime located within a central-zone in communication with a provisioned agent operating on an edge-zone device. The display control prime may implement prime-blind open-loop pixel-state control on the edge-zone device by executing pixel-state commands via the provisioned agent. The provisioned agent, operating within the edge-zone, may have access to un-sanitized data, which may be unavailable to the display control prime in the central-zone. The display control prime may provide conditional pixel-state commands via a pixel-state control parameter matrix. The provisioned agent may identify an operative pixel-state command from among the conditional pixel-state commands based on the un-sanitized data to which the display control prime is blind.

Abstract: A distributed ledger technology (DLT) network may include a plurality of participant nodes. The participant nodes may respectively validate a distributed ledger based on a consensus protocol. A blockchain export system may send, to a data receiver not included in the DLT network, a participant public key for a participant node of the DLT network. The blockchain export system may receive, from the data receiver, a request to share token data stored in a blockchain of the distributed ledger. The blockchain export system may generate a certification that the token data is stored on the blockchain. The certification may include a digital signature based on a participant private key paired to the participant public key. The blockchain system may transmit the certification to the data receiver. The data receiver may verify the certification based on the participant public key.

Abstract: A participant node of a distributed ledger network may identify a distributed federated learning (DFL) smart contract stored on a blockchain. The DFL smart contract may include an aggregation sequence. The aggregation sequence may include an ordered sequence of participant node identifiers. The participant node may generate a trained model by training a global model with training data. The participant node may detect, on the blockchain, a first transition token indicative of a first model previously aggregated by another participant node. The participant node may receive the first model. The participant node may aggregate the first model with the trained model to generate a second model. The participant node may store, on the blockchain, a second transition token indicative of the second model. A successor node identified in the aggregation sequence may further aggregate the second model with an additional model in response to detection of the second transition token.

Abstract: A master oracle may receive an oracle network identifier for an oracle network. The master oracle may receive a plurality of data messages respectively generated by the oracles. The master oracle may verify, based on respective public keys for the oracles, that each of the data messages are digitally signed by a different corresponding one of the oracles. The master oracle may aggregate the data messages into an aggregated data message. The master oracle may digitally sign the aggregated data message with a private key and public key pair. The master oracle may transmit the aggregated data message to a participant node of a distributed ledger network. A smart contract stored on a blockchain may verify the aggregated data. After receiving and verifying the aggregated data message the smart contract may execute to perform operations based on the aggregated data message.

Abstract: Systems and methods for active state synchronization between distributed ledger technology (DLT) platforms are provided. A system may store an origin blockchain compliant with an origin DLT. The system may further store a target blockchain compliant with a target DLT. The target DLT may be different from the origin DLT. The system may include a DLT object synchronizer with access to the origin blockchain and the target blockchain. The DLT object synchronizer may receive, from an exchange node, a request to synchronize an origin instance of a DLT object between the origin blockchain and the target blockchain. The DLT object synchronizer may select a target instance of the DLT object on the target blockchain. The DLT object synchronizer may format origin data from the origin instance for compliance with the target DLT. The DLT object synchronizer may synchronize the origin instance and the target instance.

Abstract: A system may provide blockchain-based storage node control for unified proof-of-storage interaction for off-chain data chunk storage. The system may include verification circuitry that may provide a challenge to a storage node to audit the storage status of a data chunk. The verification circuitry may obtain identities for the storage node and data chunk based on blockchain records. The verification circuitry may obtain a challenge answer from the storage node in response. The verification circuitry may analyze the challenge answer in view of a challenge key to confirm whether the storage node has possession of the data chunk. When the storage node has possession of the data chunk chain circuitry may add a verification record to the blockchain.

Abstract: This document describes systems, methods, devices, and other techniques for managing healthcare records. In some implementations, a computing system is provided that includes an electronic ledger, a first program module, and a second program module. The electronic ledger can store entries of medical record management events invoked by participants in a distributed computing network. The first program module can be assigned to an account of a first user on the distributed computing network and can identify (i) medical records of the first user and (ii) accounts of users other than the first user that are authorized to access the medical records of the first user. The second program module can be assigned to an account of a second user on the distributed computing network and can call the first program module to request access to a set of one or more of the medical records of the first user.

Abstract: Systems and methods for active state synchronization between distributed ledger technology (DLT) platforms are provided. A system may store an origin blockchain compliant with an origin DLT. The system may further store a target blockchain compliant with a target DLT. The target DLT may be different from the origin DLT. The system may include a DLT object synchronizer with access to the origin blockchain and the target blockchain. The DLT object synchronizer may receive, from an exchange node, a request to synchronize an origin instance of a DLT object between the origin blockchain and the target blockchain. The DLT object synchronizer may select a target instance of the DLT object on the target blockchain. The DLT object synchronizer may format origin data from the origin instance for compliance with the target DLT. The DLT object synchronizer may synchronize the origin instance and the target instance.

Abstract: A system may provide a smart contract interface for blockchain interoperability. The system receive selection parameters indicative of a furnisher blockchain and a receiver blockchain. The system may obtain, based on the selection parameters, furnisher synchronization logic and receiver synchronization logic. The furnisher synchronization logic may include instructions to lock token data on the furnisher blockchain. The receiver synchronization logic may include instructions to commit token data to the receiver blockchain. The system may generate an interoperability smart contract comprising the furnisher synchronization logic and the receiver synchronization logic. The system may deploy the interoperability smart contract to a furnisher blockchain and the receiver blockchain.

Abstract: A system may receive a request to perform a token exchange between a first account and a second account. A selected token for the token exchange may be associated with the first account. A hash of the selected token may be stored on a furnisher blockchain of a first distributed ledger. The system may generate a new token and a hash of the new token. The system may generate a shielded exchange instruction, the shielded exchange instruction comprising the hash of the new token and a zero-knowledge proof, wherein the zero-knowledge proof is indicative of the selected token being associated with the first account. The system may submit the shielded exchange instruction to a distributed ledger technology platform to cause execution of a furnisher smart contract and a receiver smart contract. Each of the smart contracts are configured to separately verify the zero-knowledge proof and update corresponding blockchains to consummate and record the token exchange.