BR112020006828A2 - declarative smart contracts - Google Patents

Abstract

It is the action of having a block in a chain of blocks added to the chain of blocks that includes making an entity receive information that corresponds to a previous block, causing the entity to receive a declarative invocation of an execution of a smart contract in a given entry, in which the declarative invocation declares relevant execution results and other relevant data, cause the entity to verify the syntactic validity of the invocation, and to cause the entity to incorporate the declarative invocation in the block in response verification of the syntactic validity of the invocation. Relevant results can specify net effects of smart contract execution, a state resulting from the smart contract after execution and a number of steps for execution. The other relevant data may specify a declarative invocation caller, time information, block information and / or a payable fee.

Description

Descriptive report of the invention patent for “DECLARATIVE INTELLIGENT CONTRACTS”

TECHNICAL FIELD

[0001] This order refers to the field of electronic transactions and, more particularly, the field of content security of transaction block sequences for electronic transactions.

BACKGROUND OF THE INVENTION

[0002] “One can think of a smart contract as a computer program that, similarly to a user, can own its own money. Such a C contract can have its own retained (computational) state, possibly modified after each invocation, and its own identifier: for example, the sequence H (C), where H is a hash function. For the sake of simplicity, this identifier is denoted by C. The reader can easily determine when C is the program itself or its identifier. Preferably, a C smart contract is easily distinguishable from an ordinary user. For a player, it means a smart contract or an ordinary user.

[0003] The execution of a smart C contract can be invoked by one or more suitable users. For the sake of simplicity, but without any intended loss of generality, it is assumed in this document that C is invoked by a single user i. * 1 After all, when C can be invoked by multiple users, often one of them executes C first , modifying its retained state, before another suitable user invokes C. The order of the appropriate users may not matter, if C is stateless. Otherwise, even if - say - two suitable users invoke C at the same time, it is possible to choose an order for both executions and wait for the first one to "finish" before executing the second one. Those skilled in the art can realize that it is possible to write C so that only if invoked by multiple C users is actually executed 'by the system' and that these contracts can also be handled by the present technology.

[0004] “A user is considered capable of invoking the execution of the system C. of the system. User i invokes C through a digital signature. Such a signed invocation of i can specify, in addition to C, an input, input, and a fee, fee. It will be elaborated below.

[0005] * + inputdetails a specific entry on which to run C. There may, of course, be additional entries, such as standard entries: for example, the current state of C, Yc (which can, in fact, be considered as an entry) and a global state of the system (for example, the amount of ownership of each player in a given block).

[0006] + fee includes an amount payable by i to compensate the system for the computational cost incurred for the execution of Cc.

[0007] —User, when invoking C, can also specify some additional information. For example, it can specify a certain block - and, thus, a certain “snapshot” in the block chain - or that the execution of contract C can have an effect on a certain block or range of blocks. Additionally, it can be thought that the entire block chain history so far can be taken into account by C. In short, there may also be additional (and possibly implicit) entries.

[0008] Atax can also include the amount i need to pay to include your invocation, like any other transaction, in the block chain. However, the latter traditional rate is ignored in order to focus on the problem alleviated by the new invention.

[00090] The number of computational steps in a C execution depends on the machine on which the execution is performed. Consequently, it is considered to compute Cf (inputl in a fixed (virtual) machine M.

[0010] An execution of C generally generates a new retained state y'c and increases or decreases the quantities belonging to some players, x, y, ..., respectively by: amount ',> amounty ,,. ..

[0011] The signed C invocation of user i can enter the chain of blocks in a given block, only if |, at that point, he has an amount of money greater than or equal to the rate, the rate specified in the invocation of |.

[0012] Traditional methods (for example, nonces) are used to prevent an invocation from actually corresponding to a single execution. Such methods are not crucial to the problem and the invention in question and are therefore ignored in this document, without any intended loss of generality. Similarly, for all types of other details independent of the invention.

[0013] Once the invocation of i enters a block in the block chain, each user u in a class of users U executes C (in the virtual machine M, using the last retained state reached by C) for an amount steps covered by fee; updates its own version of the block chain data by subtracting the rate from the amount owed by i; and, if the execution ends properly, it modifies (again, in its own version of the block chain) the quantities belonging to the players affected by the execution of C (possibly including the quantity belonging to C itself). It can refer to the execution of C by all such users as a system execution of C. Typically, class U consists of all users or a very large number of users (for example, all users who want to contribute to generate a new valid block in the block chain).

[0014] If the number of users is large, the total cost of the system can be very high, even when the number of steps is a little small. This implies that the fee paid by the summoner must also be very high, although the number of steps is not entirely high. In this situation, in a block chain system, it makes sense to execute only smart contracts that require few steps.

[0015] This is unfortunate. Users in the system can benefit from invoking the execution of many smart contracts that require a non-trivial number of computational steps, but are prevented from invoking them due to the exorbitant fees they have to pay.

SUMMARY OF THE INVENTION

[0016] According to the system described in this document, in a transaction system in which transactions are organized in blocks, the supply of new blocks B 'and B' ** in relation to a sequence of previous blocks B, B ', ..., B! * Includes having block B' built after confirming that block B 'indicates initial transaction states that are consistent with a state of transactions in block B "! block B "** is constructed after confirmation that block B" ** indicates initial transaction states that are consistent with a state of transactions in block B ", and cause a plurality of entities to verify unverified transactions previously from block B 'after block B "** is built. Transactions can be smart contracts. A user can build block B' in connection with launching a transaction for at least one of the smart contracts in block B” You can also post translation results for smart contracts in block B ". The user can also post a number of steps for executing smart contract results for smart contracts in block B ". The user can also post a fee that the plurality of entities receive to verify transactions in block B". The plurality of entities can be a subset of all users in block B ”. The plurality of entities can be chosen at random. Choosing the plurality of entities at random may include applying a cryptographic hash function to data that includes at least one of: time information, information about one or more blocks, data included in one or more blocks, or data deduced from one or more more blocks.

[0017] In addition to the system described in this document, the action of causing a block B in a chain of blocks to be added to the chain of blocks that includes causing an entity to receive information that corresponds to a previous block, cause the entity to receive a declarative invocation of a smart contract execution on a given entry, where the declarative invocation declares relevant execution results and other relevant data, cause the entity to verify the syntactic validity of the invocation, and to make that the entity incorporates the declarative invocation in block B in response to checking the syntactic validity of the invocation. Relevant results can specify net effects of smart contract execution, a state resulting from the smart contract after execution and a number of steps for execution. The other relevant data may specify a declarative invocation caller, time information, block information and / or a payable fee. Declarative invocation can be syntactically valid if the fee is adequate for the number of steps to be taken and a fee payer has sufficient assets to pay the fee, and the fee can be paid if the declarative invocation appears in the block chain.

[0018] In addition to the system described in this document, the action of causing a set of verifiers in a block chain to be assigned to verify a set S of one or more declarative invocations of smart contract executions on certain entries , where declarative invocations declare relevant results of smart contract executions, includes the verifiers that receive the set S, the verifiers that determine which of the declarative invocations in S are semantically valid and the verifiers that provide authenticated responses to one or more declarative invocations which are semantically valid. The set of verifiers can be selected based on S, in a pseudo-random way, through a certain cryptographic function. At least one verifier can determine that at least one verifier has been selected through computation involving a secret key from at least one verifier, and at least one verifier can prove to others that at least one verifier has been selected. An invocation l in S can be considered correct if the responses of at least a certain number of verifiers assigned to S indicate that | it is semantically correct.

[0019] “In addition to the system described in this document, in a chain of blocks in which a set S of declarations of intelligent contract invocations has already been registered, a set of verifiers assigned to S, and the verifiers provided authenticated responses on which of S's invocations are semantically valid, having a verdict of S's invocations incorporated into the block chain includes having an entity that receives authenticated responses from verifiers, having the entity that deducts the correction from S's invocations, and having the entity that incorporates a final verdict on the correctness of the invocations of S in the chain of blocks. The final verdict of an invocation l in S may indicate that | is correct if the responses from at least a certain number of verifiers assigned to S indicate that | is semantically valid. If the final verdict of an invocation | of S indicate that | is correct, other users may be provoked to update the status of the smart contract and consider that the stated net effects of the smart contract execution have occurred.

[0020] In addition to the system described in this document, the action of having a block B in a chain of blocks is added to the chain of blocks includes making an entity receive information that corresponds to a previous block, making causing the receipt of a compromised declarative invocation of a smart contract execution at a given entry, where the compromised declarative invocation declares at least some relevant results of the execution, a commitment to other relevant results of the execution, and other relevant data, cause the verification of the syntactic validity of the compromised declarative invocation and cause the incorporation of the compromised declarative invocation in block B in response to the verification of the syntactic validity of the compromised declarative invocation. The relevant results can specify net effects of the execution, a state resulting from the contract after execution and / or a number of steps and the other relevant data can specify an invocation caller, time information, block information and / or a payable fee. Declarative invocation can be syntactically valid if the fee is adequate for the number of steps and the fee payer has enough assets in the system to pay the fee, and the fee can be paid if the invocation appears in the block chain.

[0021] In addition to the system described in this document, the action of causing a set of verifiers in a block chain to be assigned to verify a set S of declarative invocations, including at least one committed declarative invocation | specifying an execution and a smart contract on certain entries, where | includes a commitment to at least some relevant results rr from e, includes the verifiers that receive the set S, the verifiers that reconstruct the execution and in order to compute the relevant results rr, and the verifiers that provide authenticated responses that include personalized commitments with rr of the checkers. The assigned verifiers can be selected based on S, in a pseudo-random way, through a certain cryptographic function. At least one verifier can determine that at least one verifier has been selected through computation involving a secret key from at least one verifier, and at least one verifier can prove to others that at least one verifier has been selected. The compromised declarative invocation | in S can be considered correct only if the responses of at least a certain number of verifiers assigned to S include a personalized commitment to the relevant results rr committed to |.

[0022] “In addition to the system described in this document, in a chain of blocks in which a set S of declarations of intelligent contract invocations has already been registered, a set of verifiers assigned to S, in which set S includes at least least one committed declarative invocation | which specifies an execution and a smart contract on a given entry, and on which | includes a commitment to at least some relevant results rr from e, and verifiers have provided authenticated responses to S's invocations, having a verdict on S's invocations incorporated into the block chain includes having an entity that receives authenticated responses from S verifiers, having the entity that deducts the correction of S invocations, and having the entity that incorporates in the block chain a final verdict on the correction of S invocations. Responses from at least a certain number of verifiers assigned to S may include a personalized commitment with the same relevant results rr committed to |, and the final verdict of the committed declarative invocation | in S can indicate that | it's correct. The final verdict of the | it can cause other users to update the status of the smart contract and consider that the net effects of the execution and the smart contract have occurred.

[0023] “In addition to the system described in this document, computer software, provided in a non-transitory, computer-readable medium, includes executable code that implements any or all of the steps described in this document.

[0024] “An alternative technology for smart contracts - A new technology to deploy smart contracts in a chain of blocks will be presented. The present new technology can be deployed alongside traditional ones, and can effectively handle a class of contracts that are very expensive to handle using traditional technologies.

[0025] “A great class of contracts The new technology is especially useful for smart contracts, whose

[0026] + internal / computational state (state, abbreviated) - which can change from execution to the next - and

[0027] + net effects - for example, new status, money transfers from one party to another, etc. - can be described in a compact way. It will be emphasized that the present technology allows an individual to also handle smart contracts that require

[0028] * many computational steps and

[0029] a very large amount of memory.

[0030] In fact, the memory used in one run can be very large, while the state information retained for the next run can be very compact - for example, consisting of some variables of limited value. It is important to note that stateless smart contracts trivially satisfy this property and are very powerful.

[0031] Certainly, some smart contracts may need to have a state to achieve a particular goal. In the light of the present new technology, however, it will be in the interest of the order's designers to architect such contracts in order to compact the size of their retained state.

[0032] A block chain - Agnostic Technology The technology makes innovative use of cryptographic (secret) classification, the cryptographically secure self-selection technology that is a key component of Algorand technology, which is described in PCT patent application No. POCT / US2017 / 031037 deposited on May 4, 2017, which is incorporated by reference in this document. Algorand technology is also described in most, if not all, of the patent applications incorporated in this document for reference in another section of the application.

[0033] However, despite its other advantages, it is not necessary to use Algorand as the underlying block chain platform to use the present new technology to handle a new class of smart contracts. The new technology can be used with any other platforms, such as Bitcoin, Ethereum, etc.

[0034] That said, as will be highlighted later, the use of Algorand as the underlying block chain mechanism will give rise to some additional advantages.

BRIEF DESCRIPTION OF THE DRAWINGS

[0035] The modalities of the system described in this document are explained in more detail, according to the Figures of the drawings, which are briefly described as described below.

[0036] Figure 1 is a schematic representation of a network and computing stations according to a system modality described in this document.

[0037] Figure2 is a schematic and conceptual summary of a chain of blocks that incorporates the system described in this document.

DETAILED DESCRIPTION OF VARIOUS MODALITIES

[0038] The system described in this document provides a mechanism that improves efficiency and decreases the computations needed by workstations (versifiers) to check blocks in a chain of blocks that contain smart contracts.

[0039] With reference to Figure 1, a diagram shows a plurality of computing workstations 22a to 22c connected to a data network 24, such as the Internet. Workstations 22a to 22c communicate with each other over network 24 to provide distributed transaction verification and propagation, as described in more detail elsewhere in this document. The system can accommodate any number of workstations capable of providing the functionality described in this document, provided that workstations 22a to 22c are capable of communicating with each other. Each of workstations 22a through 22c can independently perform processing to propagate transfers to all other workstations in the system and to verify transactions / blocks and act as verifiers, as described in more detail elsewhere in the present document.

[0040] “With reference to Figure 2, a chain of blocks 200 includes a plurality of blocks 202 to 205. Each of the blocks contains one or more smart contracts and additional information, as described in more detail elsewhere in this document. Block 202 is an older block in block chain 200, block 203 is the next oldest, etc. Block 205 is a newer block in block chain 200.

[0041] There can be any number of blocks in block chain 200. Each of blocks 202 to 205 contains information that validates a previous block, so that, for example, block 203 contains information that validates block 202 and block 204 contains information that validates block 203. Thus, the most recent validated among blocks 202 to 205 in block chain 200 directly validates a previous block and indirectly validates all other previous blocks. In one embodiment in this document, each of blocks 202 to 205 contains a signed hash of a previous one among blocks 202 to 205, although other mechanisms can be used to validate / confirm previous blocks, including several known conventional block chain mechanisms in the technique. In addition, one or more of the blocks 202 to 205 can be verified and may include a verdict on the authenticity of the block, as described in more detail elsewhere in this document. One or more newer blocks among blocks 202 to 205 can be initially unverified and can subsequently be verified and authenticated, as described in more detail elsewhere in this document.

[0042] Ideally, the fee for invoking an execution of a smart contract C should correspond to the total cost of computing that the execution causes the system to incur. But: What is the total cost of the system for a C execution?

[0043] If there are n users and the execution of C (on the given machine M) consists of ttsteps, then the total cost of the system can be estimated to be n x Hsteps.?

[0044] “Thus, if n is large, the total cost of the system can be very high, even when tsteps are a little small. This 2 Here it is assumed that each user checks the correctness of a new block and executes all the smart contracts that it contains. On some block chain platforms, only full nodes have this responsibility, but not light nodes. Either way, it cannot be very large.

implies that the rate payable by summoner i of C must also be very high, although tsteps is not high. In this situation, in a block chain system, it makes sense to execute only smart contracts that require few steps. This is unfortunate. Users in the system can benefit from invoking the execution of many smart contracts that require a non-trivial number of computational steps, but are prevented from invoking them due to the exorbitant fees they have to pay.

[0045] It has been found that it is convenient to describe the technology of the invention in a specific choice of parts. It should be understood, however, that each part is new in itself and can be used in isolation, and that further divisions into parts are also possible within the scope of the invention.

1. INVOCATIONS.

[0046] “A declarative invocation | of a smart contract C specifies the relevant results in an execution and of C (in certain inputs / inputs and initial state) and other relevant data.

[0047] Relevant results may include the new state reached by e and the player quantity adjustments corresponding to e.

[0048] The relevant data may include an indication of the contract, status and entries in question; the number of steps of e (in relation to a reference M machine) or an upper limit for that number of steps; and a fee, representing the cost or an upper limit for the cost that the invocation causes to the system. (As will be seen, this cost can be significantly less than that caused when all users run and.)

[0049] Relevant data may also include an indication of at least one suitable user i responsible for the invocation, and the digital signature of i (or another form of authentication), meaning that i in fact accepts responsibility for the invocation, including its cost to the system. Such user i may, in fact, have generated the execution itself in order to compute its relevant data.

[0050] The relevant data may also include an indication of a block or a set of blocks in which the invocation is expected to be officially registered, that is, appear in the block chain. (In fact, user i can waive responsibility for the invocation if it does not enter the block chain in r.)

[0051] - For the sake of simplicity, it can refer more simply to a declarative invocation | as an invocation.

[0052] Discussion and Additional Details As previously, a suitable user i invokes the C execution of the system in an entry, entry, by propagating a digital signature of the same. At this point, however, the signature of i, in addition to C, entry and a correct rate, also authenticates the effects of C's execution and the number of steps taken by the execution.

[0053] “In a sample configuration, i first computes an execution and of C (input), or some other computes and for the same, in order to find out what results the execution will have and then asks the system to confirm those results. In execution e, C starts with the retained state yc: that is, the last retained state reached by C after the sequence of executions of C registered in the block chain.

[0054] For example, but without loss of generality, i computes and initiates the propagation of 3 It should be noted that the information above can be somewhat redundant. This is for clarity and is not intended to impose any limitation. For example, the rate can be determined, using the system's current 'price list', from other quantities, such as its total length (or, for example, only the length of the effects) and / or the number of steps. Similarly, the number of steps can be limited by the rate and so on. Throughout, a mentioned quantity that can be deducted / estimated from other quantities, may not appear explicitly, but deducted / estimated.

invoke; &STG; (i, r, C, input, Hesteps, ve, 76, (x, amount!), (Y, amounts), ..., fee)

[0055] where

[0056] + -iis an identifier of the invoking user, included mainly for convenience, if deductible from i's subscription.

[0057] * Contract in question.

[0058] + r, in this example, is the specific single block in which i expects the invocation to be registered and i denies responsibility for the invocation if it is not registered in block r

[0059] + r ', possibly an indication of a future block. (For example, to convey that the invocation must be discarded if a final verdict on the execution invoked appears in the block chain by block r '.)

[0060] + input is the input (or inputs) i in which i chooses to invoke the execution of C.

[0061] + tstepséon number of e (on a given M reference machine).

[0062] * vycéo initial state y'c is the new retained state of C generated by e.

[0063] + (x, amount), (y,; amounty,), ... are the player quantity adjustment pairs generated by and.

[0064] + tax is the amount of money payable per i (in this specific example).

[0065] * + grade (expected) of the set of verifiers for the invocation (which will be discussed shortly).

[00668] <-t an integer, possibly included to indicate the number of coherent invocation responses needed to consider the invocation correct (a notion that should also be discussed shortly).

[0067] You can refer to invoke; as the invocation - from i to

C (input) - and a (i, r, C, input, testeps, vo, Ye, (£, amount ”), (y, amount), ..., fee, n, t)

[0068] - according to the declared execution summary.

[0069] The fee payable may depend on some quantities chosen, such as (without any intended limitation) tsteps, the size of the declared execution summary, and the size of the resulting state y'c. Therefore, it is important to design C so that its states are compact, and to focus on contracts whose net effects can be described in a compact way. The rate may also depend on quantities n and t, if the invocation includes such quantities. The fee may also depend on other amounts as well, such as the size of the final verdict, which should be discussed shortly. The rate is considered to be adequate if, in fact, it is equal to or exceeds the quantity corresponding to the chosen quantities.

[0070] In short, invoke; it is essentially the request for the system to verify the correctness of the declared execution summary and then (a) update the new retained state of C and (b) adjust the quantities belonging to the players affected by the execution of C.

[0071] It will now be seen as such an invocation | is registered.

2. REGISTRATION.

[0072] “One Invocation | you can enter the block chain very similar to a common payment. The invocation | it can be propagated from user to user until some user u in charge of generating a new block places it in its block. Preferably, u should check that | is syntactically valid.

[0073] Verification of syntactic validity requires verification of some simple conditions. For example, it may include checking that the initial state of C indicated in | coincides with the final state indicated in the last invocation of C registered in the block chain. Or that the summoning user, if any, is in fact authorized to do the summoning. Thus, registering an invocation in the block chain does not require the execution of C.

[0074] The syntactic validity can also include the verification that a user i who invokes | does, in fact, have enough money to pay the fee specified in |. In fact, such a fee can be paid automatically by i. (A contract can also be considered to be responsible for paying the fee - for example, due to the fact that it is a contract that called an invocation. If the fee is paid with money belonging to such a contract, then syntactic validity may include check that the contract has enough money to pay the fee. In that case, that fee can be paid automatically by the contract when | it enters the block chain.

[0075] The syntactic validity may also include the verification that the rate of | is suitable for the number of steps indicated by |.

[00768] A block that includes a smart contract invocation that is not syntactically valid is considered invalid. Consequently, an honest u must not include an invalid syntactic invocation in a new block.

[0077] The syntactic validity can also be verified during the propagation of |. In fact, a user x who receives a | not syntactically valid may not forward it to other users.

[0078] Discussion and Additional Details It should be noted that the syntactic verification of an invocation | it is typically much lighter than its corresponding semantic check. The last term means the verification that the execution of the execution is invoked by | actually yields the declared execution summary. Such semantic verification can be very long, due to the fact that a smart contract execution can take a large number of steps.

[0079] - “Consequently, it is a main advantage that, in the preferred modality, a block constructor u checks only the syntactic validity of |, but not its semantics. A typical block contains thousands of transactions and it is assumed, for example, that 1,000 of them are invocations of smart contracts, and that the execution of each one takes, on average, 1 second of computation. So, even disregarding all other computations, to build a new block u would need at least 1,000 seconds (that is, about 16 minutes), if you had to check the semantic validity of invoking the new blocks that it produces. This is, in fact, what a block contractor should do under the traditional smart contract model. However, the production of a block every 16 minutes can be very slow. It would be legitimately preferable to produce a new block in a few seconds.

[0080] This slowness would be even worse if, during message propagation, it was necessary for users to verify the semantic validity of the invocation that they forward to other users.

[0081] In the preferred mode, an invocation is considered official when it enters the chain of blocks, and only then will the system begin to make the necessary effort to verify the semantic validity. As will be seen, however, the total effort of the system will be very restrained and practical.

3. ASSIGNMENTS.

[0082] - A set S of one or more invocations of smart contract, registered in one or more blocks, is assigned to a set of smart contract verifiers.

[0083] For example, S can consist of all smart contract invocations included in a given block. Alternatively, S can consist of a single invocation. Alternatively, the invocations of a given block can be partitioned into several sets. For example, the first set may consist of the first k intelligent invocation, for some given integer k; the second set can consist of the next k; and so on. (Except the fact that the last set can contain less than k invocations.) - As in another example, a block's smart contract invocations can be partitioned (for example, in some canonical way) into multiple sets in order to control the total number of steps declared in the execution summaries of each set. For example, the first set may consist of the first k invocations in the block, if the sum X of the number of steps in your declared execution summary does not exceed a certain number N, while the sum of X and the number of steps in the execution summary declared value of the next invocation is greater than N. Set S may depend on the (expected) size of the verifier sets. For example, S can group invocations that specify a similar (expected) size of sets of verifiers.

[0084] The set of smart contract verifiers assigned to S, Vs, is sufficiently random and sufficiently numerous, to ensure that, with a high probability, most of the selected verifiers are honest, assuming that a particular majority of users are honest. . In addition, a checker in Vs can be selected in proportion to the amount of money it currently has in the system or at a given time, according to the block chain. This verifier can be selected to belong to Vs with a greater weight, which means that it has two or more votes, and it may be desired to ensure that the majority of votes are in honest hands.

[0085] Furthermore, the Vs set is preferably verifiable. That is, (a) an individual has the ability to compute Vs from S, or (b) a checker in Vs has the ability to determine that he is, in fact, a member of Vs and, if so, has the ability to prove to others that this is indeed the case.

[0086] “Discussion and Additional Details The invention assigns each set of smart contracts a relatively small set of verifiers, Vs, which will invest the time necessary to verify the semantic correction of the declared execution summaries of the invocations in S, saving others users in the system do the same job. If Vs were small and fixed, the system would not be very secure, due to the fact that an opponent could, in time, corrupt all or a majority of the checkers.

[0087] —To protect against this eventuality, each Vs is selected in a random or pseudo-random manner, based on S and some additional information P. For example, you can use a hash function or another suitable cryptographic function H: for example, Vs = H (S, P). A possible choice of P may include timing information, information about the block or blocks in which S appears, data included in that block or deductible from those blocks or, more generally, from the block chain etc., including no information. (It should be noted that Vs can be selected based on S, because it is selected based on the block or blocks where S appears. For example, if S is the set of all invocations of block B or number of block n, then Vs can be selected based on B or N. As another example, if S is the second set of invocations, in some order, of block number n, then Vs can be selected based on information that includes the pair (n, 2). The fact that it is selected based on S includes being selected based on S and other information.)

[0088] This random choice of Vs makes it much more difficult for an opponent to corrupt some of the verifiers in Vs. In fact, the set of verifiers can always change dramatically.

[0089] Ideally, the verifiers in Vs are selected using a secret classification method. In such a method, a user secretly learns whether he is a checker in Vs, but can prove it to others, if that is indeed the case. For example, v can use a secret key of the same to compute if it belongs to Vs. For example, v can compute SIGy (S, P) and check if the data sequence thus computed satisfies a certain property. Such a property, without any limitation being intended, may have the value SIGy (S, P) or its hash less than a certain number t. In fact, SIGy (S, P) like any other data stream, can be interpreted exclusively as a number, and that number is easily compared to the “target” number t. For example, if t = 0.001, then the probability that H (SIGvy (S, P)) is 1 in a thousand, if the cryptographic function H is treated as a random function. Consequently, in this example, 1 in a thousand of possible users consists of verifiers in Vs. It should be noted that the set of verifier Vs in this example is verifiable. In fact, if v belongs to Vs, then v can prove that this is the case by releasing his SIGv (S, P) signature. In fact, given this string of data, anyone could say that they have the desired property that determines that it belongs to Vs. But until v reveals SIGyv (S, P), it would be very difficult for an opponent to corrupt v, simply because do not know who v. In fact, v is selected secretly, due to the fact that it is the only one who knows the secret key (your secret signature key in the example above) that determines whether v belongs to Vs. In fact, the choice of Vs through secret classification it is very safe.

4. VERIFICATION.

[0090] “When the set of smart contracts S is registered (appears) in the block chain, each verifier v in Vs verifies the semantic correction of each invocation | in S and then authenticate and propagate your responses.

[0091] If the set Vs is selected through secret classification, then v also propagates proof that it actually belongs to Vs.

[0092] The verifier v can authenticate its answer on each | in S separately. For example, by computing and propagating SIGvy (1, valid).

[0093] The verifier v can also authenticate all its responses together, indicating which invocations are valid and which are not. For example, if the invocations in S are | 1, 12, l3, la, ..., and the invocations |, l3, ... are valid and the invocations | 2, l1, ... are invalid, then, v can compute and propagate: SIGÁ (R, valid). (Ia, invalid), (Iz, valid), (Ia, invalid), ...)

[0094] More compactly, v can use 1 to indicate validity and O to indicate invalidity. Thus, for the example above, you can authenticate all your answers together by propagating SIGA 1), 02.0), 03.1), (14.0); ---) even more compactly, if the invocation in S, | l1, 12, la, la, ..., they are actually ordered in some predetermined and unambiguous way, in the case above v can propagate SIGvy (1, 0, 1, O, ...). That is, the first 1, which is in the first position, indicates that the first transaction, that is, l1, is valid; the first O, which is in position 2, indicates that the second transaction, that is, | 2 is invalid; and so on.

[0095] The verifier v can also authenticate its responses together, however, in order to allow extracting the authenticated response from v about an individual invocation in S. For example, v can build a Merkle tree, each leaf from the same store the response of v on a separate invocation in S and then can authenticate the value stored at the root of the Merkle tree.

[00986] An honest Vs checker just provides the correct answer (and thus a single answer) about each lemS invocation.

[0097] “Whatever the method that verifiers in Vs can use to authenticate which invocations of S are considered valid and which are considered invalid, an invocation | in S can be considered correct, if at least a certain number X of the verifiers in Vs authenticates that | it is semantically valid, and otherwise incorrect. Alternatively, | can be considered incorrect if at least a certain Y number of verifiers in Vs authenticates that | it is semantically incorrect. To maximize significance, X and Y are chosen to be large enough that, when most verifiers in Vs are honest, (a) each invocation | in S that is semantically valid be considered correct and not considered incorrect; and similarly, (b) each invocation | in S that is semantically invalid it will be considered incorrect and will not be considered correct.

[0098] “Discussion and Additional Details Having verifiers in Vs that propagate their authenticated responses about the semantic validity of invocations in S is not enough. For example, a user who recently joined the system and learned the entire chain of blocks so far may have no idea what was propagated before joining. Consequently, although I see that an invocation | was registered in the block chain, does not know if | is correct or not. Therefore, it is important to record a final "verdict" on | in the block chain itself.

[0099] “Remember that Merkle trees are well known in the literature. A Merkle tree allows to authenticate many pieces of information, stored in the nodes of the tree, in relation to the value r stored in the root of the tree. To authenticate any v value stored on a node in the tree, it is necessary to provide an authentication path, from root to the node that stores v. Such a trajectory can be much shorter (for example, logarithmically shorter) than the sequence of authenticated values in the tree. If the value r is not known, to authenticate a value v stored in a node in the tree, an individual can authenticate r separately (for example, via a digital signature) and then provide an authentication path for v against r.

5. VERDICTES.

[00100] A user u who builds a new block can include in that block not only valid common transactions (for example, valid payments) that do not yet appear in the block chains, but also the final verdict, that is, information about the correction or the inaccuracy, as the case may be, of invocations previously registered in the chain. Preferably, such information is provided for transactions for which no final verdict has yet appeared in the chain.

[00101] S is considered as a set of invocations previously registered in the block chain and u is a user who builds a new B block. Then, after receiving the answers from sufficiently many verifiers in Vs - in order to learn, for each | in S, if | is correct or not - u can include in B the final verdict on S invocations (for example, all S invocations). Such a final verdict may also include information that identifies the set S itself and is preferably authenticated. If u authenticates B, then this verdict is automatically authenticated by u. Alternatively, u can separately authenticate the final verdict on summons in S. For example, to specify the final verdict on summons in S, u can use one of the methods used by a verifier in Vs to convey his answer about the semantic validity of summons in S S.

[00102] Alternatively, u can include in the block the authenticated responses of sufficiently many Vs verifiers to allow it to be determined from such included responses, invocations in S that are valid and invocations of S that are not. Possibly, along with such responses, u may also include one or more strings of data, proving that the verifiers in question actually belong to you.

[00103] Alternatively, u can include in its block the answers about S of some Sv verifiers, preferably verifiers whose answers have not yet been registered in the block chain, although the correction of invocations in S cannot be deduced only from of such information included. However, a user can deduce the correction of S invocations over multiple blocks. The final verdict on an invocation | de S can, in fact, be achieved when sufficient responses recorded in the chain attest to the correction or incorrectness (whatever the case may be) of |.

[00104] User u can include in B's information about the correction of all invocations in S, or just one or more of them. For example, it may include in B one or more verifier responses in Vs about one or more invocations | in S. Or it can include information from which a person can deduce the correction of at least some transaction (or transactions) in S. If the verifiers in Vs authenticate their answers about the validity of invocations in S in a way that allows them to a person extract their authenticated response on just a few transactions | in S, then u can include such authentication extracted over |. For example, if a verifier v in Vs authenticates this response to invocations in S by authenticating the root r of a Merkle tree, then to include in B the authentication of v of an invocation | in S, u can include authentication of v of r and an authentication path of r for a value that includes response from i on the validity of del.

[00105] Discussion and Additional Details. A block B can be considered valid not only if its common transactions were valid,

but also if your final verdicts on invocations previously recorded are valid.

[00106] In a chain of blocks that depends on proof of work in order to produce new blocks, honest mining does not link a new block to an invalid block.

[00107] In a block chain, like Algorand, where a new B block is proposed and then voted or established by appropriate sets of users (for example, an appropriate set of verifiers) in order to be added to the chain, an invalid block may probably not be voted on or established.

[00108] The protocol may allow the simultaneous execution of a given contract, or impose a specific order of execution among C executions, which include neglecting some of those executions. For example, if an invocation | of a given C contract is registered in the block chain, the protocol can prevent another invocation of C from being registered in the block chain, until a final verdict on | appear in the block chain. In particular, a user u who builds a new B block may not include in B two or more executions of C. Alternatively, two or more invocations of C may appear, however, one of them is chosen (for example, in some predetermined way) to run first. The other (or others) can never be performed, or performed only after a final verdict! about the first one having been achieved. Alternatively, one is chosen to be executed first and then the second and so on, depending on the type of contract and what the contract specifies.

[00109] An invocation | of a C contract can also include a block number r, so that no final verdict on | can enter the block chain after block r. Alternatively, such r can be determined automatically, based on the block in which | is registered and the number of steps declared in |. This allows for a new C invocation if the original has remained without a final verdict. In such a case, it is possible to consider automatically reimbursing the user responsible for the invocation | for the fee paid when | has been registered in the block chain.

[00110] Since (an indication of) the final verdict of an invocation | of a contract C enters the chain of blocks, if the verdict is positive, then a user x who realizes this appropriately updates the current state of C and considers all the relevant net effects that have occurred. (For example, if the invocation | declares a given form of payment from one user to another user, then the money acquired by such users is automatically updated.) If the final verdict is negative, then no update of C status occurs and no net effect occurs. However, an additional fee can be automatically imposed on the user responsible for the invocation.

1 GENERAL ANALYSIS

[00111] Safety, Efficiency and Cost The response of a single verifier v on the invocations of a given set S would be sufficient, if a person was certain that v were honest. However, obviously, a builder / proponent block or any other may not know which verifiers are honest. However, it is easy to be confident about the honesty of most verifiers. Thus, if sufficient verifiers, preferably selected at random, inform all other users which invocations of S are valid and which are not, then it is possible to learn the correction of invocations of S, without having to verify its validity properly! This is why the inventive scheme is both safe and efficient at the same time.

[00112] For example, if 80% of users are honest, the number of | in S it is about 500, so the response from 300 verifiers can, in fact, ensure extremely high security. At the same time, if S contains, for example, 100 invocations, then, on average, only 5 users check the validity of each invocation, which makes the system extremely efficient, in addition to being extremely secure.

[00113] Since relatively few verifiers (especially on average!) Directly check the validity of a declared execution, in which the fee required to register a given execution can be very low. In fact, it is necessary to reimburse the computational costs of very few users: in the example above, only 5 users, on average, instead of - say - all users in the system. The fee required to invoke a smart contract is often called "gas". Consequently, in the inventive system, Gas is much more economical for different and desirable types of contracts!

[00114] Optimal security, coupled with optimum efficiency, and low costs can make the inventive system very attractive for a large class of smart contracts, and can, in fact, allow for the large-scale use of such contracts.

[00115] In fact, with the inventive system, smart contracts can have a much longer execution time than in other systems, which still causes a much smaller amount of total computation.

[00116] Weighting for Money It is noted that, throughout this request, the set of Vs verifiers of a given set of invocations can be selected, as in Algorand or other block chains, at least partially based on some form of proof of bet, based on the amount of money you have in the system at any given time (for example, when S is registered in the block chain). In fact, a given user can enter Vs with a multiplicity greater than one. In fact, Sy can consist of a number of votes from a set of verifiers, where each verifier can have more votes, depending on the amount of money he has. That is, the inventive system also applies when it is assumed that most of the money is in honest hands.

[00117] Computational Efficiency Note that, although n, the number of users in the system, can be huge (for example, n = 100M), only T (for example, T = 500) verifiers need to execute C (input). Thus, the total computational cost of a C execution with the inventive technology is <500 steps instead of 100 M steps. Consequently, smart contracts in Algorand can have a much longer execution time than in other systems, and still cause a much smaller amount of total computation. In other words, the new technology enjoys much greater flexibility and allows the use of a much larger class of smart contracts.

[00118] Cost Efficiency The computational efficiency of the new smart contract technology automatically assumes cost efficiency. Consider invoking an execution of a smart C contract that requires 1 hour of computing on a system with 100 M users. In such a system, the rate of a traditional C invocation is required to be necessarily very high, as it must essentially cover the total cost of 100 M of computing hours. On the other hand, with the new technology, the corresponding fee for the same C invocation should only cover 500 hours of computing. In fact, this last cost is not only modest, but also remains the same even if the total number of users in the system is IB or higher! Put another way, in the new inventive system, “Gas” is much more economical for different and desirable types of contracts!

[00119] Productivity Efficiency With inventive technology, an invocation | of a contract C registered in a block B triggers the execution of C, through a set of appropriate verifiers, “chain disconnected. Thus, even if such an execution takes a long time, it does not take much time to check the validity of block B. Thus, the generation of the next block can begin immediately. In other words, the inventive system can have a very high yield. Once the appropriate | conclude their executions, even if such execution takes too long, the final verdict on | enters the block chain without slowing down the chain. On the other hand, in the traditional method, if | is launched in block B, the invocation of and must be completed before the next block is produced. Therefore, the new technology makes it possible to produce new blocks in a few seconds, even if the blocks contain smart contracts whose executions required individually or in total, one hour of computation.

2 VARIANTS AND ADDITIONS

[00120] Above, the preferred modality of the inventors was presented. Those skilled in the art realize that many other variants and alternatives are possible, all of which fall within the scope of the invention. Below, only a few of them were considered.

[00121] Final Verdicts without Registration of Invocation In the preferred modality, an invocation | must be registered in the block chain, in order to trigger its “system execution”. Alternatively, however, | may not be placed in the block chain, however, (an indication of) your final verdict may. For example, | it can only be propagated, until it is perceived and processed by a sufficient number of its verifiers, who then propagate their individual responses over |, and only once does it observe sufficient coherent responses, if the builder of a new B block includes in information from B on the final verdict of |. (For example, signed individual responses from some verifiers or sufficient verifiers from |.)

[00122] Additional Measures and Consequences In invoking a smart contract, the number of steps taken is an important measure of the complexity of the invocation, and the final payments / effects are some of its important consequences. However, there are additional measures and consequences, and they can all be dealt with within the inventors' invention. Below some examples are detailed.

[00123] Smart contracts could be arbitrary programs, and the execution of a C contract can automatically trigger other executions of C itself, or other smart contracts. (Often, in fact, smart contracts are written in full Turing language.) This fact can be an advantage, but also a disadvantage, and a person may wish to contain the number of calls that an invocation | of contract C can cause to be made.

[00124] For example, the number of calls, number of calls, can be specified within the invocation; (as a separate component and / or as part of other components), and the fee, fee, of | can be adjusted to depend on the number of calls. Such dependency can be simply proportional, or it can increase dramatically with the number of calls. A checker | therefore, you may be asked to verify which number of calls is correct, and also the rate, in relation to all measures of complexity, which include the number of calls.

[00125] Alternatively, or additionally, a person can limit the number of calls. For example, if the declared number of calls is greater than a given call, or if the number of C calls actually becomes greater than the number of calls, then, regardless of the number of steps and rate, the invocation is considered invalid. All of the mechanisms discussed above for individual and final verdicts apply directly to this new measure of complexity.

[00126] In addition, a person can distinguish between ordinary calls and 'nested calls'. For example, if an execution e of C, causes the execution e 'of contract C, and the last one, in turn, causes the execution e ”of a contract C”, then, e ”can be considered a nested call, of “Level 2. Similarly, a person may have nested calls of level 3, 4, etc. Note also that nested calls and / or their levels can be declared in an invocation |, and the rate, validity and handling of | can be extended directly to include this additional declared information.

[00127] A person may also consider, in addition to the direct net effects of an invocation, the effects of his calls. For example, a person can indicate explicitly in | the total amount of money needed to be transferred, either directly or through your calls. Again, a person can prohibit calls at a given level, or make them more expensive than regular calls.

[00128] Incentives. Verifiers for an invocation or set of invocations can be encouraged through appropriate rewards. In particular, an invocation checker | may be eligible for a reward if your answer about | agree with the final verdict on |.

[00129] All or some (for example, a sample of) such verifiers can be rewarded. The verifiers to be rewarded can be selected cryptographically (for example, through cryptographic sorption and / or through the help of a random flag). Alternatively, such verifiers can be selected through a block constructor. The rewarded verifiers of an invocation | (or a set of summons S) and the final verdict of | (or * Such a sample could also be selected through a specialized part, which can properly be selected again quite frequently. In particular, such part can be properly selected through cryptographic draw, by digitally signing one or more verifiers for receive a reward, and your subscription may appear on the block.

of S) can be indicated in the same block.

[00130] For example, a building block u can insert the final verdict V for | (or S), as well as information that identifies one or more verifiers v to be rewarded. (Alternatively, information that identifies the rewarded verifiers can be inserted into a subsequent block, and possibly also selected by another constructor / proposer block.) For example, u can also include in the block chain proof that a verifier v is, fact, assigned to check | (or S), in addition to the final verdict V, in order to allow verification of the possibility of the answer of v agreeing with V. Alternatively, the constructor may omit to include V in that block. For example, it is sufficient to include only v and the individual digitally signed verdict of v, for a single verifier v of | or for multiple such verifiers whose responses are consistent. In fact, from such individual responses, it is possible to deduce which final verdict V must occur. For example, if the block contains only the individual answer about | of a single v verifier, then this information can be used to indicate that the final verdict on | coincides with the individual verdict of | (and possibly also indicates that v was targeted for a reward). All rewarded verifiers can be paid automatically once identified in a block.

[00131] An honest block builder can choose the verifier (or verifiers) from | to be rewarded randomly, or in some other way. Even if a malicious builder may choose them differently (for example, by preferring malicious scanners) the | they are still encouraged to report their true responses. In fact, most verifiers are expected to be honest, and so they are, in expectation, block builders.

[00132] Furthermore, in order to reward verifiers for one or more invocations |, or for their individual verdicts to be taken into account, evidence may be required that verifiers have in fact performed C correctly. Such evidence may include some form of CS evidence, a snark or a stark. Such verifier-provided evidence could also be used and thrown in a block as part of (or the entire evidence about) the | final verdict.

[00133] In addition to positive rewards, the block chain can also use punishments. For example, a verifier v that reports a response on an invocation (or set of invocations) that is different from the final verdict on its correction, may be fined. Such a fine can be automatically deducted from the money you have.

[00134] The block chain may also consider purposely registering at least one invocation in the block chain | which is semantically invalid. This can help locate (and possibly punish) verifiers designed to verify semantic validity |, which maliciously report that | it is semantically valid (either directly or when reporting on the validity of a set of invocations that include |).

[00135] For example, users who provoke the registration of invocations that are purposely semantically invalid may not do this because they are malicious, but because they have been selected to help locate malicious scanners. Preferably, therefore, the selection of these helper users is secret (so that the verifiers of a purposely invalid invocation semantically have no idea that the invocation is so invalid) and random (in order to ensure that at least some honest helper users have selected). For example, the process used to select such helper users may be similar to that for selecting a v checker for an invocation | or a set of invocations S: a helper user can be selected by digitally signing a given quantity deductible from the chain of blocks along with other data (for example, the string “HELP USER”), scribble the signature and verify that it is less than a given target number. This process ensures that other users do not realize that a given user u has been selected to be a helper user, until u reveals proof of their selection (in the example above their digital signature). This evidence can be revealed after a final verdict on a purposely invalid invocation semantically | registered by u having entered the block chain. Such proof can be inserted in the block chain as a valid transaction. In this way, the fee, or any fine that was imposed on u, can be automatically refunded to u (possibly, in addition to a reward), once anyone realizes that u have tied in accordance with the protocol to help ensure honest operation. of smart contracts in the block chain.

3 DECLARATIVE INTELLIGENT CONTRACTS

COMMITTED

[00136] A special type of smart declarative contracts is now described: committed smart declarative contracts (CDSC, for short). The invocations of such contracts temporarily conceal at least some net effects of the corresponding executions. These invocations can be recorded as before. Its syntactic validity can be verified as before. Verifiers can be assigned to the sets of such invocations as before. And, the final verdict can be cast on the block chain as before.

[00137] However, verifiers of these new invocations do not verify their semantic validity as before. This is because these new invocations temporarily hide at least some of the net effects of the executions they specify. These invocations include,

in fact, a commitment to such net effects. (Such a compromise hides such liquid effects, however, at one point in time later, but leaves the door open to probably reveal, at some point in time later, what the net effects originally compromised were.)

[00138] Thus, a verifier assigned to verify such an invocation | can reproduce the execution and specified by |, which learns what all the net effects of and are, however, cannot determine whether the net effects compromised in | are those that he computed himself. Consequently, in this response, such a verifier reports his own personalized commitment to the net effects of e that he himself computed and committed to |, without knowing whether their values match. Such a personalized commitment cannot be obtained by just copying the corresponding commitment in |, and it cannot be reliably computed from the last commitment, or from any other personalized commitment. In fact, the idea in a CDSC is to compel a | to learn what the net effects hidden by | and then compute and include in your response your own commitment to such effects. In a sense, therefore, each | must act independently and actually execute the execution and called by.

[00139] Only at a later point, the inventive system reveals information that allows verifying the correction of |, allowing to verify if the net effects compromised in | coincide with the compromised net effects (in a personalized way) on responses from sufficient | verifiers. Consequently, a final verdict on an individual summon or a set of CDSC summons can be launched in the block chain, and incentives and / or punishments can be allocated to users as before, and also in new ways.

[00140] Without any intended restrictions, additional details of CDSCs are described.

1. COMMITTED INVOCATIONS.

[00141] A compromised declarative invocation | of a C contract specific to an execution and of C (in the given entry / entries and initial state) and other relevant data, much like a declarative invocation, however, it hides a set s of net effect of e, including, in instead, a commitment to s.

[00142] A commitment to a given value x allows you to secretly establish x at a given point in time, however, to prove at a point in time later what the established value x was. For example, to commit to a set of net effects s, | can include h = H (s), for a given (collision resistant) hash function H. In fact, s is difficult to compute from h, if you have no idea about s. At the same time, eventually disclosing s convinces anyone who knows that the revealed is in fact the original compromised amount. This is because it is difficult to compute any value z is s so that H (z) = H (s). Alternatively, | you can commit to a set of net effects, separately including the hash value of each of these effects. For example, if s consists of a new state of C generated by e, y and the player's quantity adjustments generated by e, qa1, a2, * * -, then | can commit to s including H (y '), H (ai), H (a2), .... Still, alternatively, | can commit to a set of net effects Ss including the root value of a Merkle tree whose nodes store the net effects in question. More generally, the inventive system can use other methods of compromise to temporarily hide some net effects of |.

[00143] The relevant data of a declarative invocation (at least partially) of a smart contract can be as in a common declarative invocation.

[00144] For the sake of simplicity, it is possible to refer, simply, to a compromised declarative invocation | as a declarative invocation, or, even more simply, as an invocation, if the context is clear enough. In order to emphasize that an invocation of a smart contract is not a compromised declarative invocation, it is possible to use the term common invocation.

[00145] Discussion and Additional Details The discussion and additional details about common invocations that are applicable in committed declarative invocations are automatically extended to the latest invocations.

[00146] It is noted that a compromised invocation, digitally signed by an appropriate invocation user, continues to authenticate all the net effects of the relevant C execution, although a set of them can be authenticated in an indirect way, that is, by authenticating a commitment to s.

[00147] As it should be seen, the inventive system allows all users who observe the chain of blocks to determine whether a compromised invocation | of a C contract is correct, without overloading all users or many users to compute the execution and specified by |.

[00148] Now it will be seen as such a compromised invocation | is registered.

2. REGISTRATION OF COMMITTED INVOCATIONS.

[00149] A compromised invocation | can enter the chain of blocks as a common summon. For example, the syntactic validity of | may be enough that | enter the block chain.

[00150] Verifying such syntactic validity may include verifying whether the rate of | is suitable for the number of steps declared in | for the specified run. In fact, the rate and declared number of steps may not be considered to be net effects of execution and specified in | that must occur in the block chain. Consequently, the rate and declared number of steps can openly appear in |.

[00151] Again, a block that includes a syntactically invalid committed invocation is considered invalid, and the syntactic validity of a compromised invocation | may be necessary to forward | to other users during the propagation of |.

[00152] When a compromised invocation | is registered in the block chain, the system begins the process of verifying its correctness. We will now proceed to illustrate this process.

3. ASSIGNMENTS OF COMMITTED INVOCATIONS.

[00153] A set S of one or more committed smart contract invocations, registered in one or more blocks, is assigned to a Vs set of verifiers, after any of the methods described for assigning a set of common invocations.

4. VERIFICATION OF COMMITTED INVOCATIONS.

[00154] When the set S of committed invocations is registered in the block chain, each verifier v in Vs executes contract C of each invocation | S in the appropriate entry (or entries) and state, and then authenticate and propagate your responses. As already mentioned, such responses may include only a personalized commitment to some of the net effects of execution and specified in | Now some possible examples of such responses will be discussed.

[00155] If | is flagrantly invalid (for example, if the number of steps in your invocation and exceeds that stated in |), then v indicates that this is the case in your answer about S. For example, including in your answer the pair ( |, invalid).

[00156] In a second example, leave and be the execution called by (specified in) |, leave | declare the correct number of steps for e, let ne consist of all the net effects of e, presented in a predetermined manner and order, and let | hide ne including H (ne) impairment. Then, after rebuilding e (and thus ne), v can authenticate information that identifies | and a commitment, preferably personalized, with ne. Through a “personalized commitment of v with ne, one must understand commitment hy with ne so that (a) it is difficult to compute hy without knowing ne— even though v knows the commitment H (ne) included in | and may also know other commitments to ne— and (b) be easy for anyone, given the knowledge of dene and v, to compute v's personalized commitment to ne.

[00157] For example, a personalized commitment from v to ne can consist of Hy (ne), where H, is the hash function thus defined: Hy (x) = H (v, x). Thus, h = Hy (ne) = H (v, ne) is, in fact, a commitment of v to ne. In fact, no one can find another value ne ', so that H (v, ne') = h, and once the value ne is revealed, no one can verify that, in fact, h = H (v, ne) . Furthermore, this compromise of v is customized, since v cannot easily compute it from the compromise H (ne) provided in |, nor from H (z, ne) if z * tv.

[00158] Note that mixing v together with ne is just one example of a personalized commitment of v with ne, and no limit is desired. For example, replacing v in H (v, ne) with any data preferably depends only on v, it would also work. Any form of personalized commitment to ne is within the scope of the invention.

[00159] (As for common invocations, if the set Vs is selected through a secret draw, then v, in addition to your answers, also propagates proof that, in fact, it belongs to Vs-. Again, v can authenticate your answer on each committed summation | in S separately, or together, as well as in the case of common summons. *)

[00160] Use a personalized commitment to the net effects of execution and a compromised invocation | makes it difficult for a v checker in Vs to authenticate that | is valid - even if v was sure that the invocation | was properly prepared! - without learning what the value ne is - for example, by actually executing the execution and called by |. At the same time, by learning ne, anyone can verify that the value ne, whose commitment is included in |, and the value whose personalized commitment by v is included in the response of v over |, are equal.

[00161] Correction of Committed Invocations. An honest Vs checker provides only the correct answer, and thus a single answer, for each compromised invocation | in S. Such an invocation | is considered (to be proven) correct if the hidden net effects compromised in | are equal to the net effects compromised in the responses of at least a given number X of the verifiers in Vs. Invocation | can be considered incorrect if at least Y verifier responses in Vs indicate that | is invalid. Alternatively, | can be For example, if the invocations in S are | 1, | 2, 13, la, m .., and the invocations | 1, l3, ... are valid (and have, respectively, the net effects ne :; nes ...) and invocations |, la ... are flagrantly invalid, so v can compute and propagate GIS, ((li, Hy (nei)), (l2, invalid), (la, Hy (nes) ), (la, invalid), ...). Again, more compactly, if 1, l2, la, la ... are the invocations of S in a given order, then v can authenticate and propagate the sequence (Hv (ne1)), O, Hv (nes), O0 , ...), where O indicates that the corresponding invocation is flagrantly invalid. Verifier v can also authenticate its responses together, however, in order to allow the authenticated response of v to be extracted from an individual invocation in S. For example, v can construct a Merkle tree, each leaf of the same stores the response of v on a separate invocation in S and then can authenticate the value stored at the root of the Merkle tree.

considered incorrect if, at a given point in the block chain, it has not proven to be correct yet.

[00162] Note, however, that without knowing ne it is difficult to determine whether H (ne) = H, (ne). Thus, the system needs some way to determine which compromised invocations are correct. Several of these ways are described below.

4.5 REVEALING HIDDEN NET EFFECTS.

[00163] Let the appropriate party you invoked | and let ne be the net effects of the execution and specified by |, whose commitment appears in |. Leave, without loss of desired generality, the way to compromise ne in | consist of a hash value of ne. When assuming that | it is honest, so presumably i (1) knows the value ne; (2) computed and appropriately included in | the H (ne) impairment; and (3) it is desirable that the net effects do not actually occur in the block chain.

[00164] Consequently, when i observes that more than X verifiers v in Vs include a personalized commitment to ne - for example, H, Y (ne) - in their responses, i propagates ne, preferably in an authenticated manner and with information that identify invocation l.

[00165] Once ne is revealed, anyone who looks at the block chain messages realizes that the value ne is the same value committed to | and in the personalized commitments of the responses of at least X of the verifiers in Vs. In other words, every observer sees that the compromised invocation | it's correct.

[00166] Note that it is not necessary that the summoner i reveal ne. For example, it can be any entity (for example, a special verifier assigned to a committed S set of invocations to which | it belongs) that performed and, computed ne and realized that, in fact, ne is the same committed to | and personalized commitments for responses from at least X of the verifiers in Vs.

[00167] Now is the time to make this achievement in the block chain official.

5, VERDICTS ON COMMITTED INVOCATIONS.

[00168] Let | be a compromised invocation already registered in the block chain, however, not having a final verdict. Then, a constructor u of a new block B, who realizes that | is correct, it includes in information from B that indicate that | is correct, thus, a final verdict on | is provided.

[00169] The system can also provide the simultaneous final verdict of all committed invocations on a set of committed invocations S already registered in the block chain, for which no final verdict exists yet.

[00170] For example, a user u who builds a new block B, who has learned which invocations in S are correct, may include in B a final verdict on such invocations in S. Such a final verdict may also include information that identifies the set itself S, and is preferably authenticated. If u authenticates B, then this verdict is automatically - * authenticated by u Alternatively u can separately authenticate the final verdict on invocations in S.

[00171] Alternatively, u can include in the block the authenticated responses from sufficient verifiers of Vs, in order to allow to determine, from such included responses, invocations in S that are valid and invocations in S that are not. In doing so, you can use any of the methods covered in the case of common invocations.

[00172] Discussion and Additional Details. A block B can be considered valid not only if its common transactions were valid, but also if its final verdicts on previously registered invocations (common or committed) appropriately reflect the correction of such invocations.

[00173] Another discussion and additional details described for common invocations also apply to committed invocations. This is also true for several variants and additions presented for common invocations.

[00174] In particular, however, without desired limitation, the weighting for money techniques also applies to the verifiers of committed invocations. Consequently, a tester with weight n can be treated as n separate testers.

[00175] Verifiers whose response to a compromised invocation | complies with the established correction of | and / or with the established revealed value of the net effects committed in | they can be rewarded — for example, through any of the incentive methods already described, the common summoners or New ones.

[00176] Similarly, verifiers whose response to a compromised invocation | does not agree with the established correction of | and / or with the established revealed value of the net effects committed in | they can be fined or punished - for example, through any of the incentive methods already described, the common verifiers. In particular, they may become ineligible because they are assigned to verify at least some other invocations.

[00177] The caller of an incorrect compromised invocation | you can also receive special fines or be punished in some way.

4 VARIANTS AND ADDITIONS.

[00178] Let s be a set of net effects of execution and specified by a compromised invocation | of a smart contract C, and let h = H (s) be the commitment to s included in |. Then, some part - for example, a verifier assigned to |, such as a verifier assigned to a set of invocations that includes | - would have difficulty computing s from H (s), if s were itself unpredictable enough. However, if s consisted of - say - just a few bits, then it would be possible for some party to try all possibilities for s until a value is found that mixed yields h. To avoid this possibility, one could choose s as very large - for example, to consist of all the net effects of e, in order to make it more difficult for one party to guess everyone in its entirety. However, even that could sometimes not be enough.

[00179] To ensure that the compromised net effects of and are difficult to guess correctly, it is possible to artificially include in these liquid effects a specially chosen quantity that is difficult to predict. For example, although the net effects of and that you care about were the new state y 'and some adjustment of player quantity, A1, ..., dk, ONE appropriate summoner of | it could artificially add to these liquid effects the content, x, of a special auxiliary variable of C at the end of the execution e, and leave s = (Y ', d1; ..., ak, x). In fact, even though the net effects of e may always be easy to predict, the computation of e can have, or can be modified to have, quite unpredictable variable content in order to generate its simple effects. Thus, if x is difficult to predict, s = (Y ', d1: ..., Ok, x) it would be difficult to predict from H (s), even if Y, d1; ...., Ok is easy to predict. (Naturally, x would have a purely auxiliary role and should not be treated as a liquid effect that occurs in the block chain if the invocation | is correct.)

[00180] Alternatively, the value x could depend on e and the execution of a specified program possibly separated entirely P, in a specified entry totally separated y contained in, or deductible from, |. Such a program P and input y can be chosen so as to make x difficult to predict from P and y. For example, the computation of P may include from time to time quantities obtained from execution e. Alternatively, the computation of P (y) can be completely independent of e.

[00181] Again, | can contain a commitment to x, and a verifier v, assigned (directly or indirectly) to verify the execution and of |, can also be asked to compute x and include a custom commitment to x in that response. Only if the underlying values of these custom verifier commitments are sufficiently assigned to | coincide with each other, and with the underlying value x committed to |, | can be considered correct. Thus, a verifier assigned to | is encouraged to properly compute x if you want your answer on | be properly counted.

[00182] Note that in any of the variants described above and other possible variants that those skilled in the art can use, the total number of steps declared in | it would also have to include the number of steps needed to compute x and thus can make the payable rate of | increase. However, an appropriate summoner of | can be happy to pay a higher fee, so you are more confident that a | appropriately computes x.

[00183] Furthermore, no matter how this x value is used, it may even be possible for | include the actual net effects of e— for example, those that should, in fact, occur in the block chain, if | is correct - in an open manner, and have a personalized commitment to x to be the only commitment to |. In this case, a verifier v, assigned to a set S that contains |, is asked to produce a response (1) that indicates whether the openly stated net effects of and are correct and (2) that includes a custom commitment to x. In that case, the invocation | is considered correct if the value of x committed to | coincides with the value committed in the responses of sufficient verifiers v assigned to S, and such responses indicate that the openly declared net effects of | are correct.

[00184] Note that the mechanism described in this document is applicable in other block chain systems in which it is desirable to randomly choose a subset of users for a particular purpose, such as verification, in a way that is generally verifiable. Thus, the system described in this document can be adapted to any other block chain schemes, such as Ethereum or Litecoin or even block chain schemes that are not directly related to money.

[00185] The system described in this document can be adapted to be applied in and combined with mechanisms presented in all or any of the following US Patent Applications and POT: 62 / 117,138 filed on February 17, 2015, 62 / 120,916 filed on February 26, 2015, 62 / 142,318 filed on April 2, 2015, 62 / 218,817 filed on September 15, 2015, 62 / 314,601 filed on March 29, 2016, PCT / US2016 / 018300 filed on 17 February 2016, 62 / 326,865 deposited on April 25, 2016, 62 / 331,654 deposited on May 4, 2016, 62 / 333,340 deposited on May 9, 2016, 62 / 343,369 deposited on May 31, 2016,62 / 344,667 deposited on June 2, 2016, 62 / 346,775 deposited on June 7, 2016, 62 / 351,011 deposited on June 16, 2016, 62 / 353,482 deposited on June 22, 2016, 62 / 354,195 deposited on June 24 of 2016, 62 / 363,970 deposited on July 19, 2016, 62 / 369,447 deposited on August 1, 2016,62 / 378 .753 deposited on August 24, 2016, 62 / 383,299 deposited on September 2, 2016, 62 / 394,091 deposited on September 13, 2016, 62 / 400,361 deposited on September 27, 2016, 62 / 403,403 deposited on 3 October 2016, 62 / 410,721 deposited on October 20, 2016, 62 / 416,959 deposited on November 3, 2016, 62 / 422,883 deposited on November 16, 2016, 62 / 455,444 deposited on February 6, 2017, 62 / 458,746 deposited on February 14, 2017, 62 / 459,652 deposited on February 16, 2017, 62 / 471,562 deposited on March 15, 2017, 62 / 507,074 deposited on May 16, 2017, 62 / 510,905 deposited on May 2017, 62 / 522,927 deposited on June 21, 2017, 62 / 536,061 deposited on July 24, 2017, 62 / 541,568 deposited on August 4, 2017, 62 / 548,201 deposited on August 21, 2017, PCT / US2017 / 031037, deposited on May 4, 2017, 15 / 551,678 deposited on August 17, 2017, 62 / 564,670 deposited on September 28, 2017, 62/567 .864 deposited on October 4, 2017, 62 / 570,256 deposited on October 10, 2017, 62 / 580,757 deposited on November 2, 2017, 62 / 607,558 deposited on December 19, 2017, 62 / 632,944 deposited on 20 February 2018 and 62 / 643,331 filed on March 15, 2018, in which all are incorporated by reference in this document.

[00186] Deployments of system software described in this document may include executable code that is stored on computer-readable media and executed by one or more processors. Computer-readable media can be non-transitory and include a computer hard drive, ROM, RAM, flash memory, portable computer storage media, such as a CD-ROM, a DVD-ROM, a flash drive, an SD card and / or other unit with, for example, a universal serial bus (USB) interface, and / or any other tangible or non-transitory computer-readable media or appropriate computer memory in which the executable code can be stored and executed by a processor. The system described in this document can be used in combination with any appropriate operating system.

[00187] Other embodiments of the invention will become apparent to those skilled in the art from a consideration of the specification and practice of the invention disclosed in this document. It is intended that the descriptive report and the examples are considered as examples only, and the scope and true spirit of the invention are indicated by the following claims.

Claims (30)

UT CLAIMS 1. Method for providing new blocks B 'and B "** in relation to a sequence of previous blocks Bº, B', ...., B"), in a transaction system in which transactions are organized in blocks, the method being characterized by the fact that it comprises: causing block B 'to be built after confirmation that block B' indicates initial transaction states that are consistent with a state of transactions in block B "! cause block B "** to be built after confirmation that block B" ** indicates initial transaction states that are consistent with a state of transactions in block B '; and cause a plurality of entities to verify transactions not previously verified from block B 'after block B ”** is built. 2. Method, according to claim 1, characterized by the fact that transactions are smart contracts. 3. Method, according to claim 2, characterized by the fact that a user builds block B 'in connection with the launch of a transaction for at least one of the smart contracts in block B ”. 4. Method, according to claim 3, characterized by the fact that the user also posts transaction results for smart contracts in block B ”. 5. Method, according to claim 4, characterized by the fact that the user also launches a number of steps to execute the results of smart contracts for smart contracts in block B ”. 6. Method, according to claim 5, characterized by the fact that the user also launches a fee that the plurality of entities receives to verify block B transactions ”. 7. Method, according to claim 1, characterized by the fact that the plurality of entities is a subset of all users of the Br ”block. 8. Method, according to claim 7, characterized by the fact that the plurality of entities is chosen at random. 9. Method, according to claim 8, characterized by the fact that the choice of the plurality of entities at random includes applying a cryptographic hash function to data that includes at least one of: time information, information about one or more blocks, data included in one or more blocks or data deducted from one or more blocks. 10. Method for making a B block in a block chain to be added to the block chain characterized by the fact that it comprises: making an entity receive information that corresponds to a previous block; cause the entity to receive a declarative invocation of a smart contract execution at a given entry, where the declarative invocation declares relevant performance results and other relevant data; cause the entity to verify the syntactic validity of the invocation; and having the entity incorporate the declarative invocation in block B in response to checking the syntactic validity of the invocation. 11. Method according to claim 10, characterized by the fact that the relevant results specify at least one of: net effects of smart contract execution, a state resulting from the smart contract after execution, and a number of steps for execution and where the other relevant data specifies at least one among: a caller of the declarative invocation, time information, block information and a payable fee. 12. Method according to claim 11, characterized by the fact that the declarative invocation is syntactically valid if the fee is adequate for the number of steps to be taken and a payer of the fee has sufficient assets to pay the fee, and in which the fee is paid if the declarative invocation appears in the block chain. 13. Method for having a set of verifiers in a block chain to be assigned to check a set S of one or more declarative invocations of smart contract executions in certain entries, where declarative invocations declare relevant results of contract executions intelligent, and the method is characterized by the fact that it comprises: the verifiers that receive the set S; the verifiers that determine which of the declarative invocations in S are semantically valid; and verifiers that provide authenticated responses to one or more declarative invocations that are semantically valid. 14. Method, according to claim 13, characterized by the fact that the set of verifiers is selected based on S, in a pseudo-random manner, through a given cryptographic function. 15. Method according to claim 14, characterized by the fact that at least one verifier determines that the at least one verifier has been selected through computation involving a secret key from at least one verifier, and in which the at least one a verifier can prove to others that at least one verifier has been selected. 16. Method, according to claim 13, characterized by the fact that an invocation | in S is considered correct if the responses from at least a certain number of verifiers assigned to S indicate that | it is semantically correct. 17. Method for getting a verdict of S invocations to be incorporated into the block chain, in a block chain where a set of declarative smart contract invocations has already been registered, a set of verifiers assigned to S, and the verifiers provided authenticated responses about which invocations of S are semantically valid, characterized by the fact that it comprises: with an entity, receiving authenticated responses from verifiers; with the entity, deduct correction of S invocations; and with the entity, incorporate in the chain of blocks a final verdict on correcting the invocations of S. 18. Method, according to claim 17, characterized by the fact that the final verdict of an invocation | in S indicates that | is correct if the responses of at least a certain number of verifiers assigned to S indicate that | is semantically valid. 19. Method, according to claim 17, characterized by the fact that, if the final verdict of an invocation | of S indicates that | is correct, have other users update the status of the smart contract and consider that the stated net effects of the smart contract execution have occurred. 20. Method for making a B block in a block chain added to the block chain characterized by the fact that it comprises: making an entity receive information that corresponds to a previous block; cause the receipt of a committed declarative invocation of a smart contract execution at a given entry, where the committed declarative invocation declares at least some relevant results of the execution, a commitment to other relevant results of the execution and other relevant data; cause verification of the syntactic validity of the compromised declarative invocation; and cause the committed declarative invocation to be incorporated into block B in response to checking the syntactic validity of the compromised declarative invocation. 21. Method, according to claim 20, characterized by the fact that the relevant results specify at least one of: net effects of execution, a state resulting from the contract after execution, and a number of steps and in which the other relevant data specify at least one of them: an invocation caller, time information, block information and a fee payable. 22. Method, according to claim 21, characterized by the fact that the declarative invocation is syntactically valid if the fee is adequate for the number of steps and the fee payer has sufficient assets in the system to pay the fee, and in which the fee is paid if the declarative invocation appears in the block chain. 23. Method for having a set of verifiers in a block chain to be assigned verify a set S of declarative invocations, including at least one committed declarative invocation | specifying an execution and a smart contract on certain entries, where | includes a commitment to at least some relevant results rr de e, characterized by the fact that it comprises: the verifiers that receive the set S; the verifiers that reconstruct the execution and in order to compute the relevant results rr; verifiers that provide authenticated responses that include personalized appointments with verifiers' rr. 24. Method, according to claim 23, characterized by the fact that the assigned verifiers are selected based on S, in a pseudo-random manner, through a certain cryptographic function. 25. Method according to claim 34, characterized by the fact that at least one verifier can determine that at least one verifier has been selected through computation involving a secret key from at least one verifier, and in which the hair at least one verifier can prove to others that at least one verifier has been selected. 26. Method, according to claim 23, characterized by the fact that the compromised declarative invocation | in S is considered correct only if the responses from at least a certain number of verifiers assigned to S include a personalized commitment to the relevant results rr committed to |. 27. Method for getting a verdict of S invocations to be incorporated into the block chain, in a block chain where a set of declarative smart contract invocations has already been registered, a set of verifiers assigned to S, where the set S includes at least one committed declarative invocation | which specifies an execution and a smart contract on a given entry, and where | includes a commitment to at least some relevant results rr from e, and the verifiers have provided authenticated responses to the invocations of S, characterized by the fact that it comprises: making an entity receive the authenticated responses from the verifiers; make the entity deduct correction from the invocations of S; and make the entity incorporate in the chain of blocks a final verdict on the correction of the invocations of S. 28. Method, according to claim 27, characterized by the fact that the responses of at least a certain number of verifiers assigned to S include a personalized commitment with the same relevant results rr committed to |, and in which the final verdict of declarative invocation committed | in S indicates that | it's correct. 29. Method, according to claim 28, characterized by the fact that the final verdict of the correction of | causes other users to update the status of the smart contract and consider that the net effects of the execution and the smart contract have occurred. 30. Computer software provided in a non-transitory computer-readable medium characterized by the fact that it comprises: executable code that implements the method, according to any of the preceding claims 1 to 29. ; FIG. 1 »FIG. two