Initial Draft for EIP-Rules-Engine

[jaerith]

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

• The PR edits only existing draft PRs.
• The build passes.
• Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
• If matching on email address, the email address is the one publicly listed on your GitHub profile.

[lightclient]

@jaerith I'm not sure why the CI failed here. Could you force push your last changes to retrigger it?
Edit: Actually it may not retrigger with the same hash, but I believe closing and reopening the PR will retrigger.

[jaerith]

@jaerith I'm not sure why the CI failed here. Could you force push your last changes to retrigger it?
Edit: Actually it may not retrigger with the same hash, but I believe closing and reopening the PR will retrigger.

I made another small change to trigger the integration. Still want me to try closing and reopening the PR?

[lightclient]

@jaerith I ran the eip-validator locally and I realized that you also need to update the file name of your EIP to eip-2746.md. I think that will solve the CI issues (although still not sure why there was no output).

[jaerith]

@jaerith I ran the eip-validator locally and I realized that you also need to update the file name of your EIP to eip-2746.md. I think that will solve the CI issues (although still not sure why there was no output).

Ah ha! I thought that the file got renamed as part of the integration process. Okay, I'll change the name.

[MicahZoltu]

I think the idea here is good, but it is unclear to me why this needs to be a standard. It seems that this would be better suited as a contract/dapp. Generally speaking, the benefit of having an ERC standard defined in an EIP is when you have a many-to-many relationship, meaning you'll have many contracts interfacing with many different clients. In this case, it seems like there will likely be a single contract that may have many clients talking to it. When the relationship is one to many, you can simply publish a contract to the blockchain, publish some documentation on how to interface with it, and then people can build clients against it.

The above is my personal opinion on EIPs (I generally prefer to standardize less, as standardization leads to calcification). As an EIP editor however, these changes look fine. If you still want to move forward with an ERC given the above mention me in a comment and I'll merge this for you.

[jaerith]

The above is my personal opinion on EIPs (I generally prefer to standardize less, as standardization leads to calcification). As an EIP editor however, these changes look fine. If you still want to move forward with an ERC given the above mention me in a comment and I'll merge this for you.

Hi @MicahZoltu,

Thanks for the compliments about the idea! In general, I'm also laissez-faire when it comes to the idea of standardizing, especially since most standards become unused anyway (due to usually being too abstract). But in this case, I think that such a standard could help with mainstream consideration of Ethereum, especially with enterprises. As the case with the Baseline protocol, it's my hope that any proposals that focus on business transactions could attract the involvement of enterprise, even before Ethereum 2.0. Hopefully, this standard (or another like it) would be implemented and used by both the enterprise companies themselves (like a supplier in a pipeline) and software vendors who build solutions as services (as you had suggested). In the case of the latter, I could see a many-to-many scenario as part of a vendor solution, where each client has its own deployed instance that can interact with other client instances (i.e., one company's RuleTree calls another). Also, by having a standard interface in the case of vendor solutions, it might help to prevent vendor lock-in, so that the clients could easily move to a different vendor. Perhaps clients might even standardize and reuse the same rules (like validating a VAT calculation) by sharing them via IPFS or FileCoin in a standard markup form.

Most importantly, though, I don't expect this interface to be the final version of what's really needed. Instead, I think that it can help serve as the starting point for discussion, to talk about introducing the possibility of a rules engine into the Ethereum space. It's my hope, actually, that others will become involved to make this proposal better than I ever could! So, yes, please move this forward with an ERC. And if you have any ideas for this proposal, I would love to hear them!