Some questions on data contracts

stan.distortion

stan.distortion

Well-known member
Layer one validation methods, can they be used in data contracts, can a valid Dash address be a required field for example?
Can a document be editable by more than one identity, for example, if an app had voting as user created documents could the app delete them after the vote?
Are there any guidelines on structuring data contracts, for example, should the aim be a single large data contract covering every aspect or are a lot of small contracts covering each aspect ok?
Is there a way of watching for changes, new documents on a contract or changes to a field for example?
Can another contract be a validation, ie, a data contract id as a field in another data contract, a document within a document that's validated by its own data contract?
Can documents have a time to live, ie. they're automatically deleted after a month?
Is there a built-in way of replacing a contract, ie. a new version is registered and users of the existing contract are automatically forwarded to the newest version?

Thanks.
 
Last edited:
Hello!

Thank you for your questions.

Some of the things that you asking are available already, some of them are planned, some of them we probably didn't think of yet.

Let me go through them one by one:

> can a valid Dash address be a required field for example?

You can mark as required any field, but there is no JSON Schema format "dash address". We could introduce it after MVP. I will add a task to the backlog.

> Can a document be editable by more than one identity, for example, if an app had voting as user created documents could the app delete them after the vote?

This will be possible after the implementation of ACL functionality for Data Contracts. It's already planned for after MVP.

> Are there any guidelines on structuring data contracts, for example, should the aim be a single large data contract covering every aspect or are a lot of small contracts covering each aspect ok?

Unfortunately, we don't have such a document yet. At some point, we are going to introduce some relational/transactional logic between different documents in a data contract so I would recommend keeping them together in the scope of your app. The only reason to decouple documents is to create a service data contract that will be used in several applications.

> Is there a way of watching for changes, new documents on a contract, or changes to a field for example?

Not yet, but we planned this functionality for post MVP.

> Can another contract be a validation, ie, a data contract id as a field in another data contract, a document within a document that's validated by its own data contract?

Hm... We didn't think about it yet. Could you please make an example?

> Can documents have a time to live, ie. they're automatically deleted after a month?

We planned this functionality for post MVP

> Is there a built-in way of replacing a contract, ie. a new version is registered and users of the existing contract are automatically forwarded to the newest version?

Yes, we just implemented such functionality (https://github.com/dashevo/platform/pull/52) and it will be delivered with v0.22 version pretty soon. The only constraint is that your changes in a data contract schema must be backward compatible (previously created data must be still valid against the new schema). If you need to break compatibility you can always create an additional contract and use old and new once depending on your application logic.

Thank you for your interest in the project. I hope you'll find useful this information and feel free to ask more.
 
Very useful, thanks :) At the very least it's saved me several days of faffing around with contract updating routines!

>> Can another contract be a validation, ie, a data contract id as a field in another data contract, a document within a document that's validated by its own data contract?

>Hm... We didn't think about it yet. Could you please make an example?

A real world equivalent: To get a valid vehicle tax certificate here two other documents are needed, a valid insurance certificate and a valid roadworthiness cert (all from different sources). I was thinking along those lines, the tax doc couldn't be created without valid doc id's for the other two.

Re, valid addresses. Validation for all the transaction logic makes sense to me, re-using the clients script handling functions in the database but I know nothing about the inner workings of databases, those routines should already be well optimised and come for free but 'free' is rarely that simple. My thinking is that would allow complex transactions to be built automatically, multisig for example, different docs for each stage so each party just has to fill in the blanks.

Thanks again.
 
> A real world equivalent: To get a valid vehicle tax certificate here two other documents are needed, a valid insurance certificate and a valid roadworthiness cert (all from different sources). I was thinking along those lines, the tax doc couldn't be created without valid doc id's for the other two.

There are two ways to implement this:
  • Embedding those two documents inside tax certificate. It will work only in case if you don't need to query those documents separately.
  • Use specify document IDs as references in the tax cerificate. For now, we don't have any referential checks but we plan them for post MVP
> Re, valid addresses. Validation for all the transaction logic makes sense to me, re-using the clients script handling functions in the database but I know nothing about the inner workings of databases, those routines should already be well optimised and come for free but 'free' is rarely that simple. My thinking is that would allow complex transactions to be built automatically, multisig for example, different docs for each stage so each party just has to fill in the blanks.

Not sure I understood it correctly. Probably, I need a real-world example here as well.
 
Check the multisig wallet creation process here (from about half way down the page, section 8):

It's a complex process involving multiple steps by multiple parties, the short question is can Platform make that easy? I'd imagine it could (and possibly handle the created wallet too), each of the steps can be broken down into documents with strictly defined fields, ie.
One party creates a doc defining the transaction and the other parties ids, 3 of 3, 1 of 5 etc.
That doc is validated when all its fields are filled correctly and that automatically leads to wallet creation.
Similar procedure for withdrawing, docs to communicate each step with valid script components as required fields and the complete script broadcast when it's fully assembled.

Maybe I'm barking up totally the wrong tree with that, I'm only scratching the surface of the Platform docs so far and while script can be quite powerful, it's probably very restrictive compared to what might be possible with dedicated dapps but if something like that where possible I'd imagine there are a lot of use cases for documents with built-in transaction capabilities.
 
I see. Not sure it’s possible without computation on chain. We have plans to introduce VM with smart contracts and data triggers - smart contracts triggered by events form data contract providing additional validation functionality.
 
That should certainly offer more than script can accomplish. The thinking with script is that it comes for free, no need for a VM because the real machine is already in the core client script handling functions. Not sure how that would integrate with a database though, on the client side those functions should be fast and efficient but I don't know if that would translate into handling any document with a script data field efficiently too.
 
I'd wanted to ask something on submitting regular expressions as accepted json fields but I've got to read up on that more, only glimpsed at json docs so far... something just dawned on me though, time delays on documet requests. Was looking at the password manager project on incubator, not finished it yet but the key to trezors security is the time taken for the pin verification, get it wrong more than a few times and you quickly have to wait for days, years, decades... it's how a very simple password can be secure.
No idea how that translates into storing a mnomnic in a document though :/
 
You must log in or register to reply here.
Back
Top