Deterministic ProcessID Generation

[NateWilliams2]

Now that we are transitioning to an Ethless Vochain approach, we can deterministically generate ProcessIDs. There are a couple of reasons we might want to do this:

• We can embed certain information in the processID itself
  • For example, we have discussed in the past embedding information about whether a CSP process is signed or blind. This would enable the CSP to restrict users to requesting anonymous or non-anonymous signatures for a ballot.
• If users can arbitrarily assign processIDs, there is a replay vulnerability
  • A user could create a process on one chain that has the same processID as one on another chain. They could then request a signature for this processID from a CSP, and there would be no way to prove whether the signature belongs to the process on the first or second chain.

Proposal

• processID = hash(chain_ID, organizationAddress, Nonce)
  The Vochain would have to keep track of a process nonce for each Account. Thus, if a new process is created, the Vochain can recreate this processID.

• Embed proof types in processID. This could be done with processID = proofBytes + hash(chain_ID, organizationAddress, Nonce), where proofBytes is, for example, a two-byte sequence from a pre-defined set of proof types.
  This would enable the proof type to be checked without any further processing or communication, ensures the proof type can never be spoofed or edited, and could be used in the future for cases that arise similar to the CSP blind vs. signed restriction case.

[p4u]

Embed proof types in processID. This could be done with processID = proofBytes + hash(chain_ID, organizationAddress, Nonce), where proofBytes is, for example, a two-byte sequence from a pre-defined set of proof types.

Embedding some information on the proessID looks like a good idea to me, it can be useful for:

• an offchain third party verifying some stuff just from the processID
• querying in a more efficient way the Vochain state

So I'd double the bet, what about something such as: processID = chainID[8bytes] + organizationAddress[22bytes] + proofType[2bytes]

This way external tools such as the CSP could verify the chainID, the organization address and the proof type in a standalone way.

So someone could just build a CSP for its own organization or create a business based on CSP verifications (paying a subscription to the CSP will allow your organization to send up to 1000 SMS for validating users).

@brickpop @jordipainan @altergui @emmdim

CSP context here https://www.notion.so/aragonorg/Technical-description-Blind-CSP-voting-ed556aa3a20f4850978ec78b83c9e056

[p4u]

And that would allow also us to provide CSP services just for specific organizations that have a subscription of the VaaS (voting-as-a-Service) API

[p4u]

Update: processID = chainID[4bytes] + organizationAddress[22bytes] + proofType[2bytes] + nonce[4bytes]

[altergui]

this is my first dive into this layer so i can't have an opinion 😵
but i'll follow the discussion

[brickpop]

Embedding some information on the proessID looks like a good idea to me, it can be useful for

I disagree on the benefit of this, because this creates hidden protocol debt that everyone needs to be aware of, just for the sake of tha CSP getting a flag.

If the intent is for the CSP to know that something must be salted, why not passing the expected type of signature as a parameter?

• The parameter itself would only affect the elections using a CSP
• All processId's would remain "random"

Also, regarding the chainId[4 bytes], I think this wouldn't work since we're currently using chainId's like production-1.3 which take much more than 4 bytes

[emmdim]

processID = chainID[4bytes] + organizationAddress[22bytes] + proofType[2bytes] + nonce[4bytes]

Will the 22 bytes suffice as an organization address for the ERC20 use cases where this is the token address?
I understand that now yes. Not sure if in the future:
https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/

[brickpop]

In my opinion, the nonce has downsides to consider.

It limits the chances of knowing the processId to only the one communincating with the Vochain. If someone wanted to create a election via Ethereum, he/she will not have a way to know what processId to expect, because Ethereum cannot possibly get a foreign nonce.

An approach that could solve that is about having:
processId = hash(bytes(newProcessProtobuf))

This way, you don't even need to worry about any nonce, all you need is the params themselves. Since you create them, you could know the processId beforehand. The chainId should be part of the protobuf params and only two elections with the same params could collide.

[brickpop]

However, for this we would need to have a global and deterministic way to encode them, and this might relate a lot to the v2 draft proposal I made 2 months ago:

• https://github.com/vocdoni/dvote-protobuf/blob/draft/protocol-v2/src/protocol/election.proto
• An upgraded protocol definition for flexible and scalable decentralized governance #27

Right now, the issue is that a process can be created by sending a bunch of data tuples to Ethereum, whereas the oracle relays something with a completely different aspect as a Vochain TX, signed by itself.

However, if the exact bytes of the election.proto model were hashed, then:

• We could have a 1:1 mapping between Params <=> processId
• It wouldn't matter if you create a process via bytes on Ethereum + Oracle, if you go through a Gateway

The API could return the processId immediately, but this is more work on the protocol side

[emmdim]

How does

processId = hash(bytes(newProcessProtobuf))

guaranteee the uniqueness of the processId?

[p4u]

Yes, it does not guarantee the uniquness, and that should be a requirement.

[p4u]

@brickpop the nonce does not need to be incremental, just unique. Its an entropy input.

In addition, with the ethereum-less approach and the democratize oracle proposal #26 the organizationAddress is the Oracle itself, not the ERC20 owner or smart contract address.

[NateWilliams2]

If the intent is for the CSP to know that something must be salted, why not passing the expected type of signature as a parameter?

@brickpop the CSP acts independently of the Vochain, and it only communicates with the voter. The voter already passes the expected signature type, but the problem is the CSP has to trust the voter when signing the vote. Then if the Vochain expects a signatureType parameter, it would also be the voter providing this parameter. A way to avoid trusting the voter would be to include the signatureType in the vote package, and have the CSP actually decode the vote package and check the signatureType before signing, and then have the Vochain do the same. But then the CSP would be tied to a specific vote package format.

[p4u]

I'd like to push for implementing this feature ASAP since currently the ProcessID approach generation is quite broken.