Abstract: The disclosed technology is generally directed to smart contracts. In one example of the technology, a first sub-contract is initialized based on communications from a first beacon node and a second beacon node. Initializing the first sub-contract includes seeding an asset on a ledger based on the first sub-contract. One or more additional sub-contracts are initialized based on communications from the beacon nodes such that the first sub-contract and the one or more additional sub-contracts together form an enterprise smart contract, and such that each sub-contract of the enterprise smart contract interrelates to at least one other sub-contract of the enterprise smart contract. Execution of logic for the enterprise smart contract is controlled. Information associated with the execution of the logic for the enterprise contract is stored on the ledger.

Abstract: The public enclave key of each enclave in an enclave pool may be registered in an enclave pool registry, and the registry updated each time there is an enclave pool membership change. A shared enclave pool key may be derived from the public enclave key of each enclave of the enclave pool. The shared enclave pool key may be stored, in a shared key ledger, as a first version of the shared enclave key, and an updated version of the shared key may be generated and stored as another version each time there is an enclave pool membership change. The output of a cryptlet that executed in multiple enclaves may be signed with the enclave private key of each enclave in which the cryptlet executed. Each enclave signature may be compared against each version of the of the shared enclave pool key in the shared key ledger.

Abstract: The disclosed technology is generally directed to cryptographic functions for smart contracts. In one example of the technology, a request for cryptographic resources is received. The request for cryptographic resources includes a binding identity (ID). Cryptographic resources are fetched from at least one cryptographic resource pool of a plurality of cryptographic resource pools responsive to the request for cryptographic resources. Separate cryptographic resource pools of the plurality of cryptographic resource pools are pools of separate types of cryptographic resources. Which type of proof delegate code is suitable for each fetched cryptographic resource is determined. For each fetched cryptographic resource, the determined type of proof delegate code is injected into the fetched cryptographic resource.

Abstract: The disclosed technology is generally directed to secure transactions. In one example of the technology, an enclave pool is formed. The enclave pool may include a plurality of enclaves that are secure execution environments. In some examples, forming the enclave pool includes registering the enclaves of the enclave pool. A request to allocate an enclave from the enclave pool may be received. An enclave may be fetched from the enclave pool responsive to the request to assign the enclave. Cryptlet code is executed in the fetched enclave such that a payload is generated in the enclave. The payload can be digitally signed and/or encrypted by the cryptlet, and can also be digitally signed by the enclave. The fetched enclave may be deallocated.

Abstract: In one example, the cryptlet binary and a cryptlet key pair are provided to an enclave. A cryptlet key pair for the first cryptlet includes a cryptlet private key and a cryptlet public key. A cryptlet binding associated with a first cryptlet includes at least one binding. Each binding includes a mapping between the first cryptlet and at least one of a smart contract or another cryptlet. A binding identification is associated with the cryptlet binding. An output is received from the first cryptlet, such that the output is at least one of encrypted or signed by the cryptlet private key, and such that the output is signed by an enclave private key. A cryptlet identity is generated for the first cryptlet, such that the cryptlet identification includes: the hash of the cryptlet binary, the cryptlet public key, and the binding identification.

Abstract: In one example, an enclave pool is formed. The enclave pool may include a plurality of enclaves. Each enclave may have a private enclave key and a public enclave key. A shared enclave pool key may be generated from or otherwise based on the public enclave key of each enclave of the enclave pool. A first enclave may be allocated from the enclave pool to a first cryptlet. A payload of the first enclave is received. The payload of the first enclave may be signed with a first digital signature by the private enclave key of the first enclave. A payload of the second enclave may be received. The payload of the second enclave may be signed with a second digital signature by the private enclave key of the second enclave. The first digital signature and the second signature may be validated via the shared enclave pool key.

Abstract: In one example, an enclave pool is formed. The enclave pool may include a plurality of enclaves. Each enclave may have a private enclave key and a public enclave key. A shared enclave pool key may be generated from or otherwise based on the public enclave key of each enclave of the enclave pool. A first enclave may be allocated from the enclave pool to a first cryptlet. A payload of the first enclave is received. The payload of the first enclave may be signed with a first digital signature by the private enclave key of the first enclave. A payload of the second enclave may be received. The payload of the second enclave may be signed with a second digital signature by the private enclave key of the second enclave. The first digital signature and the second signature may be validated via the shared enclave pool key.

Abstract: In one example, an enclave pool is formed. The enclave pool may include a plurality of enclaves. Each enclave may have a private enclave key and a public enclave key. A shared enclave pool key may be generated from or otherwise based on the public enclave key of each enclave of the enclave pool. A first enclave may be allocated from the enclave pool to a first cryptlet. A payload of the first enclave is received. The payload of the first enclave may be signed with a first digital signature by the private enclave key of the first enclave. A payload of the second enclave may be received. The payload of the second enclave may be signed with a second digital signature by the private enclave key of the second enclave. The first digital signature and the second signature may be validated via the shared enclave pool key.

Abstract: Proof onions for transactions for smart contracts are stored. Details of the transactions are stored on blockchains separate from the proof onions. The proof onions are evidence structures for the steps taken to create any transaction for the smart contract. The proof onions include a plurality of signatures or other cryptographic proofs. A proof request that is associated with at least a first transaction of the transactions is received. A first proof onion of the proof onions that corresponds to the first transaction is retrieved. A plurality of public keys associated with the first proof onion is obtained. The plurality of public keys is used to validate the first proof onion. In response to the validation of the first proof onion, the proof request is responded to with at least an indication of the validity of the first transaction.

Abstract: Data structures stored on a distributed ledger are accessed. The data structures identify registered smart contract components that include counterparties, schemas, and contract cryptlet. A first template smart contract data structure for a first smart contract is composed on the distributed ledger such that the first template smart contract data structure is a relational data structure that includes an identifier for the first smart contract, an identifier for at least two counterparties, an identifier for at least one schema, and an identifier for at least one contract cryptlet. A first smart contract ledger instance associated with the first ledger instance is caused to be deployed, such that the first smart contract ledger instance is based on the first template smart contract data structure. The first smart contract is caused to begin execution, such that the first smart contract is based on the first template smart contract data structure.

Abstract: A method is provided for delegating behavior of a smart contract associated with a blockchain to code that is not part of the blockchain. A system directs execution by a virtual machine of the smart contract. During execution of the smart contract, the smart contract sends to a cryptlet container service, via a cryptodelegate, a request to delegate a behavior to a cryptlet that executes on an attested host. During execution the cryptlet container service identifies a host for executing code of the cryptlet in an appropriate cryptlet container. The cryptlet container service directs the identified host to execute the code of the cryptlet to perform the delegated behavior. After the delegated behavior is performed, the cryptlet container service receives from the cryptlet a response to the requested behavior. The cryptlet container service sends the response to the smart contract on the blockchain that is verified by the cryptodelegate.

Abstract: In one example, a smart contract is generated such that the smart contract includes a schema and at least two counterparties. An updated version of the smart contract is generated. The updated version of the smart contract is stamped with a version stamp. The version stamp is used to prove the validity of the updated version of the smart contract.

Abstract: The disclosed technology is generally directed to smart contracts. In one example of the technology, a first sub-contract is initialized based on communications from a first beacon node and a second beacon node. Initializing the first sub-contract includes seeding an asset on a ledger based on the first sub-contract. One or more additional sub-contracts are initialized based on communications from the beacon nodes such that the first sub-contract and the one or more additional sub-contracts together form an enterprise smart contract, and such that each sub-contract of the enterprise smart contract interrelates to at least one other sub-contract of the enterprise smart contract. Execution of logic for the enterprise smart contract is controlled. Information associated with the execution of the logic for the enterprise contract is stored on the ledger.

Abstract: The disclosed technology is generally directed to cryptographic functions for smart contracts. In one example of the technology, a request for cryptographic resources is received. The request for cryptographic resources includes a binding identity (ID). Cryptographic resources are fetched from at least one cryptographic resource pool of a plurality of cryptographic resource pools responsive to the request for cryptographic resources. Separate cryptographic resource pools of the plurality of cryptographic resource pools are pools of separate types of cryptographic resources. Which type of proof delegate code is suitable for each fetched cryptographic resource is determined. For each fetched cryptographic resource, the determined type of proof delegate code is injected into the fetched cryptographic resource.

Abstract: The disclosed technology is generally directed to secure transactions. In one example of the technology, a first enclave to be used for executing a cryptlet binary of a first cryptlet is identified. The first enclave may be a secure execution environment that stores an enclave private key, and the first cryptlet may be associated with at least a first counterparty. A cryptlet binding that is associated with the first cryptlet may be generated, and may include counterparty information that is associated with at least the first counterparty. Cryptlet binding information may be provided to a cryptlet binding key graph, and a location of a first hardware security module (HSM) that stores a key that is associated with the first counterparty may be received from the cryptlet binding key graph.

Abstract: The disclosed technology is generally directed to secure transactions. In one example of the technology, a secure encrypted communication tunnel between the enclave and a hardware security module (HSM) may be established and used. Establishing the tunnel includes the following steps. A session public/private enclave key pair, including a session enclave private key and a session enclave public key, may be derived from the public/private key pair of the enclave. The session enclave public key may be sent to the HSM. A session HSM public key may be received from the HSM. Additional information may be encrypted with the session HSM public key. The encrypted additional information may be sent to the HSM. Further encrypted information may be received from the HSM. The further encrypted information may be decrypted with the session enclave private key.

Abstract: The disclosed technology is generally directed to secure transactions. In one example of the technology, a smart contract is generated based at least in part on a schema and provided information. The smart contract may be caused to be deployed on a ledger as a smart contract ledger instance. A unique address associated with the deployed smart contract ledger instance may be received. A cryptlet binding for a first contract cryptlet that is associated with the smart contract ledger instance may be generated. The cryptlet binding may be sent to the first contract cryptlet. Responsive to a state change associated with the first contract cryptlet, an update may be communicated to the smart contract ledger instance.

Abstract: In one example, the cryptlet binary and a cryptlet key pair are provided to an enclave. A cryptlet key pair for the first cryptlet includes a cryptlet private key and a cryptlet public key. A cryptlet binding associated with a first cryptlet includes at least one binding. Each binding includes a mapping between the first cryptlet and at least one of a smart contract or another cryptlet. A binding identification is associated with the cryptlet binding. An output is received from the first cryptlet, such that the output is at least one of encrypted or signed by the cryptlet private key, and such that the output is signed by an enclave private key. A cryptlet identity is generated for the first cryptlet, such that the cryptlet identification includes: the hash of the cryptlet binary, the cryptlet public key, and the binding identification.

Abstract: The public enclave key of each enclave in an enclave pool may be registered in an enclave pool registry, and the registry updated each time there is an enclave pool membership change. A shared enclave pool key may be derived from the public enclave key of each enclave of the enclave pool. The shared enclave pool key may be stored, in a shared key ledger, as a first version of the shared enclave key, and an updated version of the shared key may be generated and stored as another version each time there is an enclave pool membership change. The output of a cryptlet that executed in multiple enclaves may be signed with the enclave private key of each enclave in which the cryptlet executed. Each enclave signature may be compared against each version of the of the shared enclave pool key in the shared key ledger.

Abstract: In one example, a first enclave for use by a first counterparty to a smart contract is identified. A second enclave for use by a second counterparty to the smart contract may be identified. Secrets associated with the first counterparty to the first enclave may be caused to be securely provided. Secrets associated with the second counterparty to the second enclave may be caused to be securely provided. A cryptlet is caused to be provided to the first enclave. The cryptlet may be caused to be provided to the second enclave. A payload is received from the first enclave. A payload may be received from the second enclave. Validation may be caused to be performed for a plurality of payloads. The plurality of payloads may include the payload from the first enclave and the payload from the second enclave.