search

ethereum-oasis-op / baseline-standard

Repository for the Baseline standards team and specification work
Creative Commons Zero v1.0 Universal
17 stars 33 forks source link

Define processes as algorithms? #121

Closed chaals closed 2 years ago

chaals commented 2 years ago

R140 - R200 (approx) define requirements for various processes.

Would it make more sense to describe algorithms for each one of these? It could make it easier to understand and implement (although different programmers have different thoughts on that, let alone non-programmers), and it would probably help clarify what to do in error states - and therefore how to detect them.

Therecanbeonlyone1969 commented 2 years ago

@chaals ... the last point is easy to answer. Any outcome that is not compliant with the requirements for each operation must lead to an abort because it is not compliant. Each requirement comes with a pretty precise list of things that need to be true and each of those things is verifiable in code -- dates, signatures, schemas etc.

As to the algorithm part, sadly we are solving not for x^2 + y^2 = 4 which has a definitive solution algorithm but rather for something akin in its variability to x^n + y^n = z^n which for n>2 is Fermat's famous last theorem. A theorem that took mathematicians 358 years and several hundred pages to prove that a solution exists for all n. That does not even delineate the actual algorithms to solve it for each n. Think of x = BPI A and Y = BPI B and Z = IVSM and n as possible, zkp prover systems, and BPI states. While the requirements are like proof that a solution is possible in certain cases, there is no proof that this is universally true. In fact there is no universality since prover systems do not mix. This is similar to the requirement in Fermat's Lst Theorem that n is a whole, positive integer. Hope this makes sense.

chaals commented 2 years ago

Hope this makes sense.

Not really. In reading the document, it seems to provide some series of related steps, with expected inputs and outputs, many carried from one step to another, that only serve a real purpose when combined and carried out in the order they are given.

That's essentially what an algorithm is.

Instead of detailing each step as a separate requirement, one could say:

"procedure X must be executed according to the following algorithm:"

A formal statement of the set of steps might be easier for many people to read. (An informal summary is probably helpful for many more people).

It might also help identify what should happen at any given point - go to the next step, or stop processing and return all states to the initial state or to some other intermediate state, or provide some kind of useful information such as a diagnostic or warning, ...

It might also simplify the set of requirements to be tested.

Therecanbeonlyone1969 commented 2 years ago

@chaals we then have a different definition of algorithms. But that is ok. I think you have a workflow in mind rather than an algorithm that shows the sequence of steps from beginning to end with inputs and outputs rather than a formal algorithm. But I am guessing here.

I invite you to make a PR with what you have in mind.

Therecanbeonlyone1969 commented 2 years ago

Stale issue -> closing for the time being.