Generic Boxes

[mpk2]

Currently, boxes are parameterized only by proposition, with a value type of Long. It seems that a lot of the code is intertwined with this assumption, but there's no particular reason why box values should be limited to Long.

One example is using String as the value type for a box in order to define access restrictions to a blockchain resource.

[kushti]

Could you provide some example? If it is about "access restrictions", so I assume restricting access to the block itself, then probably String field should be a part of a proposition?

[mpk2]

As we are developing smart contract templates, we have chosen to store a contract shared amongst members as a box with a value type that can hold the state data for that contract (sealed by a 1-of-n proposition). It's different than the above, but it is a case where the default value of Long seems unnecessarily cumbersome.

I understand that one could add additional data to the boxes, but given especially the way that boxes are handled in wallet, it seems a bit silly to do so just to end up with an extraneous Long value.

So far, we've ended up building a set of generic type structures that sit parallel to a lot of the existing pieces (e.g. Box, MinimalState, BoxTransaction, etc) all the way up to the NodeViewHolder and Application level, largely duplicating existing logic because of how tightly coupled they all are.

[mpk2]

As far as a String used for access restriction, technically transactions are access-limited by access to boxes necessary for their execution. Therefore, if one wanted to create a "permission" box, one could allow elevated user permissions (i.e. the submission of particular transactions) with the presentation of a box containing a particular string value (e.g. "Admin"). This is somewhat irrelevant for the point of the discussion now, but it was where I was going with that example.

[mpk2]

Any further thoughts on this @kushti ?

[kushti]

@mpk2 Sorry for the long reply Matt! I imagine, a contract(a box) has some number of tokens associated with it? Then value is needed. State could be made a part of Proposition, if transaction applicability depends on it (proposition could be e.g. a tuple of <state, set of possible transitions> then).

I never thought about token-less applications actually. I'll revise whether it it possible to do painless generalization regarding value field (another code review is coming, final before next Release Candidate version).

[mpk2]

Thanks! Really enjoy the work that has been put into this project. We're building out our sections as it goes along.

I think that since we're running contract templates ourselves, the contract state is sufficient to determine valid transitions itself (it's not a sandboxed Turing-complete sort of setup). Instead, the contract can locally check the validity of an executed internal transaction. What you've just written seems generally applicable, though!

We've already decided to generalise some of the structures for our project. Would it be worth submitting a pull request if you decide to revise?

[kushti]

Thanks for the great words. would be extremely happy to get pull requests.

So a contract is enough to validate transactions associated with it(no anything external is needed)? and no tokens associated with it?

[mpk2]

To be more specific, contract templates as we're currently developing them have a limited lifespan. There are 3 types of transactions for this lifespan: ContractCreation , ContractMethodExecution (perhaps better named ContractMethodInvocation), and ContractCompletion. Each of these transactions involve state validation of some sort (e.g. validating that the party is authorized to perform such a transaction). But the state transition of the contract itself as a result of these transactions (in particular for ContractMethodExecution) is simply a function of parameters and is not user-definable other than by specifying different parameters. It's then easy enough to verify that the new contract state agrees with the executed contract method.

The purpose here is for a contract to internally keep track of and modify its state of affairs as they pertain to a group of accounts. Depending on the final state of affairs at the end of lifespan, balances of cryptocurrencies within the minimal state do change. However, you wouldn't call these tokens as they are not maintained or modified during contract execution. It would be more similar to the idea that contracts in Ethereum could return ether to a user depending on their internal state.

The system can probably be envisioned in Ethereum as something like some master contract that maintains user token balances and spawns sub-contracts.

It's probably a strange use-case, but it currently matches our needs.

[mpk2]

In case I wasn't clear (I sometimes write a little too much) each type of contract transaction does rely at least partially on minimal state to validate. For ContractMethodExecution, the contract method is invoked, and the new contract state is the result. Each party can simply execute locally to update their version of the contract held in the minimal state.

[kushti]

That sounds like a proposition is a state of a (finite?) state machine . so Proposition is the machine description. Is it a good model?

[mpk2]

That's probably not a bad way to think about it. I separated this out from the proposition itself.

As it's currently implemented, the signature on the tx is checked against a list of valid parties that can interact with the contract, so the proposition right now on the contract box is a (very naive version of) 1-of-n multisig proposition like PublicKey25519Proposition. The method and params are then attempted to be executed against the state of the contract, which returns a Try[ContractBox] (more or less), depending on the checks made by the contract.

[mpk2]

I think the only reason I didn't include it in the Proposition is that it also needs to be part of the generation for the new box (i.e. new contract state)

[zihehuang]

Pull request submitted #25

[zihehuang]

@kushti Any thoughts on the PR?