Abstract: A Turing incomplete smart contracting source code for use in a blockchain network is disclosed that allows for static analysis of a smart contract at the time of publishing.

Abstract: Various systems and methods use a Merklized Adaptive Radix Forest (MARF), which is an authenticated index data structure that can be used by peers, clients, miners, and/or other participants in a blockchain network for efficiently encoding a cryptographic commitment to a blockchain state. For example, the MARF data structure can be used to represent a blockchain state as key-value pairs within an authenticated directory. The MARF data structure may include various merklized adaptive radix tries (ARTs) associated with different blocks in the blockchain, some of which may be linked together via one or more back-pointers.

Abstract: The source code of a smart contract defines a schema with a map name, a key-tuple, and a value-tuple. The key-tuple can be populated with a value associated with a native field name that is associated with the principal that created a transaction.

Abstract: Various systems and methods for using a Merklized Adaptive Radix Forest (MARF), which is an authenticated index data structure that can be used by peers, clients, miners, and/or other participants in a blockchain network for efficiently encoding a cryptographic commitment to a blockchain state is described herein. For example, the MARF data structure can be used to represent a blockchain state as key-value pairs within an authenticated directory. The MARF data structure may include various merklized adaptive radix tries (ARTs) associated with different blocks in the blockchain, some of which may be linked together via one or more back-pointers.

Abstract: An improved blockchain implementation that reduces application transaction processing bottlenecks for applications that operate on a decentralized network. For example, if an application operating on a decentralized network becomes sufficiently popular, an existing blockchain can be split into the original blockchain and an application-specific chain (or app chain) that includes blocks that only store transactions for the sufficiently popular application. A peer that is not interested in tracking transactions for the sufficiently popular application, however, does not need to track the application-specific chain. Thus, the peer can reduce the number of computational operations that are performed by simply storing block data for blocks in the original blockchain and not for blocks in the application-specific chain.

Abstract: The source code of a smart contract defines a schema for a data map with a map name, a key, and a value, and when executing the smart contract, a virtual machine calls an function that inserts the data map into a data store as defined by the data map schema, the inserted data map comprising the map name defined in the smart contract source code, a key value defined in a transaction for the key, and a value from the transaction for the value.

Abstract: An improved blockchain is described herein in which a user burn transaction can be used to increase the probability that another node is selected as a leader. For example, a node can submit a user burn transaction that references a block commit submitted by another node, and may indicate an amount of cryptocurrency being burned in the user burn transaction. The amount of cryptocurrency being burned in the user burn transaction can be summed with the amount of cryptocurrency burned in the block commit referenced by the user burn transaction to determine the probability that the node that submitted the block commit is selected as a leader. While the node that submitted the user burn transaction cannot be selected as a leader, the node that submitted the user burn transaction can share in a portion of the block reward awarded to the node selected as the leader.

Abstract: An improved blockchain is described herein in which a burn quota is used to manage the rate at which blocks in a blockchain are formed. The burn quota may define the amount of cryptocurrency that needs to be burned in order for an election to commence. If the amount of cryptocurrency that is burned in association with a particular block in the burn chain is less than the burn quota, then no election or sortition occurs in association with that block. Rather, an election or sortition may occur in relation to the next block in the burn chain if the sum of the cryptocurrency burned in the previous block and the next block exceeds the burn quota. The nodes can vary the burn quota itself based on whether an election or sortition occurred or did not occur in a manner such that blocks are formed at a consistent rate.

Abstract: A blockchain single-leader election algorithm that overcomes the deficiencies of existing blockchain implementations, such as implementations that rely on the proof of work, is described herein. For example, the single-leader election algorithm may include a series of rounds, where at most one node is selected as a leader in each round and the selected leader is able to form a new block in the blockchain. The single-leader election is not an election in which there are votes, but an election in which a node is selected as a leader at random to avoid bias, such as the bias that is present in existing blockchain implementations. Any node can become a leader, and the elections are driven by burning or destroying a cryptocurrency that is different than the cryptocurrency provided to a node as a block reward and transaction fees when the node is selected as a leader.

Abstract: A storage server communicating with a backend storage provider, such as a cloud-based provider, performs processes for backing up encrypted data in the backend storage in a data cache shared by multiple decentralized applications, to allow a user of a frontend client to revert to a prior version of an encrypted file if that encrypted file has been compromised by one of the decentralized applications, where the storage server performs no encryption of the data and is not exposed to encryption keys.

Abstract: A client-side, bearer token-based decentralized authentication system and associated method are, from a user's perspective, similar to familiar, centralized third-party authentication techniques.

Abstract: An improved blockchain is described herein that allows nodes to optionally generate a proof of work nonce separate from the proof of work nonce present in a burn chain. Generation of the proof of work nonce requires the consumption of energy, and the value of the proof of work nonce can be mapped to an amount of energy consumption. Similarly, an amount of energy consumption can be mapped to an amount of a cryptocurrency. For example, the mapping may indicate how much cryptocurrency could have been produced by the node if the consumed energy was instead put to mining the cryptocurrency. Thus, the node can submit a block commit that indicates the separate proof of work nonce and the amount of cryptocurrency burned. The node can aggregate the mapped amount and the amount burned to determine a probability of the node being selected as a leader.

Abstract: An improved blockchain implementation that uses proof-of-transfer to overcome the technical deficiencies of proof of work and proof-of-stake implementations is described herein. For example, the proof-of-transfer process may include elements of a single-leader election sortition, but modified to cause base chain cryptocurrency committed for the purposes of the sortition to be transferred to a burn address or at least one reward address.

Abstract: An improved blockchain implementation that uses proof-of-transfer to overcome the technical deficiencies of proof of work and proof-of-stake implementations is described herein. For example, the proof-of-transfer process may include elements of a single-leader election sortition, but modified to cause base chain cryptocurrency committed for the purposes of the sortition to be transferred to a burn address or at least one reward address.

Abstract: A frontend client system and associated frontend method perform processes for backing up encrypted data in backend storage, such that a frontend client can perform the backup without exposing the encrypted data, using the client-controlled keys, and without long running server-side processes.

Abstract: A Turing incomplete smart contracting source code for use in a blockchain network is disclosed that allows for static analysis of a smart contract at the time of publishing.

Abstract: A Turing incomplete smart contracting source code for use in a blockchain network is disclosed that allows for static analysis of a smart contract at the time of publishing.

Abstract: An improved blockchain implementation that reduces application transaction processing bottlenecks for applications that operate on a decentralized network is described herein. For example, if an application operating on a decentralized network becomes sufficiently popular, an existing blockchain can be split into the original blockchain and an application-specific chain (or app chain) that includes blocks that only store transactions for the sufficiently popular application. Multiple application-specific chains can be formed as different applications become sufficiently popular. The original blockchain may be used to perform sortitions to select which miners should mine new blocks in the application-specific chain(s).

Abstract: In a decentralized system based on a blockchain, a storage server directs the off-chain storage of shared data for multiple decentralized applications in data caches on a backend storage provider, such that a user's client and any authorized decentralized applications can access encrypted data in the data caches, but the storage server performs no encryption of that data and is not exposed to encryption keys and unauthorized decentralized applications cannot access the encrypted data.

Abstract: In a decentralized system based on a blockchain, a system and method automates the process for migrating data for decentralized applications stored off-chain between backend storage providers, such as cloud-based storage providers, such that a frontend client can perform migration processes without exposing encrypted data, using client-controlled keys, and without long running server-side processes.