I have been thinking about HoloContract for a while and finally recognized that my mind is in a loop and stuck.
I decided to share all my thoughts here and invite you to help me to polish, correct or delete some or even all parts of it.
Smart Contract as we know in Ethereum doesn’t have any place in Holochain ecosystem. So a virtual machine which is running a code and preserving a state and then bills you some amount of gas, generally is a tiny version of our HoloPort and hApps. Apart from many details and issues in smart-contract like oracle problem, we are far ahead of this meaning.
Naturally, a contract is nothing just peace of agreement with the signature of parties that brings some commitments on the table. So contracts are not supposed to run any business logic, it is the job of each parties. Contract is just a place that I am putting my signature and then I will provide or receive some services based on that.
All kind of tokens in Access Control or Security Systems and etc, are just a digital contract between 2 parties, but with a lot of overhead and difficulties to issue and maintain them.
To not mix-up the contracts meaning in Holochain and traditional smart-contract, I would like to select HoloContract for naming.
HoloContract use cases
So let’s see initially what kind of contracts we can have inside Holochain:
Digital-Contract
In this contract 2 parties can have a tamper proof of a document as a contract. So each party just maintaining a Private-Entry of full version of document(like title, body or attachment and etc) with a reference to the Public-Entry on DHT with the Hash of contract. The Public-Entry have been signed by 2 parties during the process of contract. The unchangeable public entry will prove the correctness of each agent’s contract.
Generally this contract is my initial idea for shifting the mindset from issuing access token to Signature and Digital-Contract . (This one actually is a big challenge to me to reach a proof of concept.)
This contract is an alternative to our current solution for subscription. Resources as a Private-Entry and then capability token as an access token and then Public-Entry as a gateway.
So why not a contract? which mean we can create a specific type of Subscription-Contract. Type could be Gold or Silver Membership, Admin-User and etc. Then provider and subscriber can go for a new instance of multi-signature contract. Then we follow the road map of Private-Entry as a resource and one public entry, point or function as a gateway but decorated by the contract type. If an agent wants to access private resources via a Public-Entry he needs to bring his contract address and his signature. if he already signed that contract the door will be opened to him. Consequently it is the agent who is responsible for revoking keys or identity. And also our Public-Entry can support multiple contracts. For instance a resource which is available for Gold and Silver members.
Multi-signature contract enables us to support complex scenarios for private resources. Like approve scenario which means the contract should be also signed by another agent as an approver to be enabled.
Contract can have a meta-data like start or end date and etc. plus trigger process like payment.
Any other contract…!
There are bunch of other type of contracts in my mind like escrow account, but at the end I am reaching to the same stage that all of them are just simple Digital-Contracts after a certain steps. In escrow account example, I provide my Signature to a flow process of business rules and at the end of passing the conditions, it will sit in a contract as a signature and my agreement.
So let’s see what else we will discover at the end.
HoloContract level of implementation
In holochain, we can have HoloContracts in 3 levels:
Core level: which supposed to be codded and released by hdk and any hApp is going to use it like others core functionalities.
Zome level: that looks like an ERC20 in Ethereum. Templat of contracts will be available via crate and cargo so any hApp easily reuse and modify it in it’s own fashion.
DNA level: so we need to implement stand alone HoloContract hApp which is going to be an office of a notary. In this case we would have the meaning of B2B or B2C or C2C contracts. Digital contracts would be a peer to peer agents contract as C2C. While Subscription-Contract is a B2C contract. One part of a contract is a DNA that providing some services.
Actually that is it. If I find more topics in my mind I will keep here updated.
Looking forward to hear from you.
The human-level protocol for coming to Agreements is called Conversation for Action which will need to synchronize distributed state machines as per the diagram on that link.
I’m starting to think about UI/UX ideas now, so if you or anybody else want to be part of the conversation, let me know and we can figure out where to discuss.
A related idea, which will probably come later, is that of composable contracts, which you can search for and find lots of nice documents about how to assemble new contracts from re-usable components.
thank @bhaugen for your reply. I have read these agreement links you provided.
Actually Conversation for Action looks like BPM(business process management), however we can also call it kind of agreement or contract.
It seems you need to have IF…Else, Join…Fork, Transition Conditions(before, after), Re-hydrate state and all other things that we need in a workflow engine. Generally I can guess you need all of them in a supply chain system that totally make sense.
But the HoloContract that I am thinking about is targeting regular hApp business rules in peer-to-peer fashion using all of the cryptography tools.
In Subscription-Contract example, I started to review the purpose of issuing tokens. From access control to identity or API tokens and etc. with all the overload actions we need to have for issuing and maintaining tokens in our peer-to-peer fashion that enable user to consider their Identity and revoking their keys.
Issuing tokens in the centralize architects makes sense, but in the p2p architecture that agent brings his Identity, it seems we need to go for a new solution like Contracts and Signatures!!!
Responding because this feels like a very important conversation to follow. I think that, if a pattern emerges and becomes standard like ERC20, that makes life easier for all devs.
In addition to the above, I wonder if this HoloContract concept can be extended to also implement a general privileges model, and how far this can be taken. Just trying to map out some things:
Access to private resources is controlled by capability tokens and exercised through node-to-node messaging.
Read access to public resources is controlled by membership in the DHT.
Write privileges on public resources is controlled by validation rules, which may or may not include contracts that show that an authority has granted this privilege.
Therefore, could we have a pattern that’s similar to HoloContracts with its private entries and capability tokens, but is meant for public resources and doesn’t require the authority to be online? I’m thinking of something like public key certificates, where a recognised authority publishes a signature that says “yes, X can do Y”, and then X always produces that signature whenever they try to do Y.
I’m interested in doing a subscription/membership zome.
The mvp use case is to operate a freemium happ. A user would have to pay a periodic fee in holofuel to get access to an happ or parts of an happ.
The basic idea is a zome that bridges to the holofuel happ and verifies that an agent has done a transaction of a certain amount to a specific address before a certain date.
Maybe some cron-like agent would check if a subscription has expired and add an ‘expired’ entry on the DHT, or peers would do that check themselves when ‘dealing’ with that agent (as part of validation).
The hard part seems to be the ‘before a certain date’. It might require some time oracle or notary system.
@pauldaoust thanks for your comments.
Actually I implemented a prototype for Subscription-Contract term and instead of using capability token I used the concept of Digital-Contract.
Just as a reminder: In Barcelona hackathon @artbrock explained how to implement subscription using capabilities.(this video) and then @philipbeadle and @freesig Implemented this example. https://github.com/freesig/subscription_barcelona
So I would like to ask you to take a look at my prototype implementation and let me know what do you think? (look at test scenario in project)
By the way, I need to mention since we have an issue in multi-signature entry which stopped me to finish Digital-Contract, I just implemented a fake-contract for prototype version. Fake-Contract should be replace later with a real digital contract.
BlockquoteTherefore, could we have a pattern that’s similar to HoloContracts with its private entries and capability tokens, but is meant for public resources and doesn’t require the authority to be online? I’m thinking of something like public key certificates, where a recognised authority publishes a signature that says “yes, X can do Y”, and then X always produces that signature whenever they try to do Y.
Nice question! As I mentioned earlier, it depends of the level of implementation. in the Core or Zome level of implementation all contracts would be on the same DHT with the application DHT, so there is not any issue here because there is no 3rd party. The topic is valid when we have all contracts on another DNA as a stand alone service.
So this is my initial solution for that: Digital-Contract instead of JWT
There is an application X and Alice is a provider and Bob is going to subscribe for the content inside X app. They both started a process and created a Digital-Contract on another hApp named HoloContract.
At the end of process, X app would create a multi-signature Public-Entry with a linked address to the original contract with some metadata. This Public-Entry is going to play a role like JWT in traditional system. this Public-Entry is not the original contract, but it is valid based on the metadat(expiration date or etc) when this Entry is expired, on a new call for accessing data of subscription, they need to bridge the 3rd party application again, and create another multi-signature Public-Entry with new metadata.
So great to see this conversation guys. I have also been thinking about this a lot and how we would implement a smart contract on holochain and whether we even wanted to if there was a better way of doing it such as a holocontract?
As you may know part of my OASIS API that powers my Our World project is to provide a bridge between hc, blockchain, IPFS, SOLID, Activitypub and everything else out there to connect everything to everything and be like a network of networks or the abstraction layer over the whole internet.
Im currently working on a new project which will integrate ethereum smart contracts with holochain… so as you can see this is the perfect time for me to be having this conversation…
I wish to be able to make ethereum smart contracts callable and fully integrated into holochain but after reading through all your comments it looks like more thought may be required in this area than I first realised…
I would love to hear your feedback on what I am doing and if there is a way it could be improved and would love to collaborate with @hedayat and others on finding some good reusable solutions for all…
P.s loved the past dev camp @hedayat! You did a great job, well done bro! I had been waiting for a nice real life tutorial and example like that for a while and you did a great job explaining it… I now have a good reference example to base my new hApp project off… I’m not allowed to share the details of this new project yet… but it is being built on top of my OASIS API and Our World platform and will be one of the first satellite apps that plug into it as part of the new OAPP (OASIS App) Ecosystem I will be building…
Like you, I would also really appreciate anyone who wants to help me… thanks.
I have also been thinking about this a lot and how we would implement a smart contract on holochain and whether we even wanted to if there was a better way of doing it such as a holocontract?
I had been waiting for a nice real life tutorial and example like that for a while and you did a great job explaining it… I now have a good reference example to base my new hApp project off… I’m not allowed to share the details of this new project yet… but it is being built on top of my OASIS API and Our World platform and will be one of the first satellite apps that plug into it as part of the new OAPP (OASIS App) Ecosystem I will be building…