> For the complete documentation index, see [llms.txt](https://valargroup.gitbook.io/shielded-vote-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://valargroup.gitbook.io/shielded-vote-docs/overview/comparison-to-today.md).

# Comparison to Today

This page compares the Shielded Vote protocol to how Zcash governance works today.

## Custody

The biggest improvement in Shielded Vote is custody as a user.

### Today

Today user's must install a new wallet and import their seed phrase. This causes a lot of problems.

### Shielded Vote

We hope for Zashi integration, and are building everything off Zashi fork in hopes that this is mutually agreeable (we will change anything to help make this the case). But even if not, users can still feel safe in their hard wallet. All signing is keystone compatible, with no risk of fund loss. Thus users can feel comfortable even if they had to install a new wallet.

![keystone image](https://122492677-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpfoEiLCDh4nDIPZ0ak0t%2Fuploads%2Fgit-blob-f784f60bd885c6dcbc3d92fade04924ad37bfcfe%2Fkeystone_auth.png.jpg?alt=media)

You clearly see the FROM amount as 1 zatoshi (if we made this 0, keystone does not display any fields, making the UX more confusing), and the tx fee being 0. Thus you know its not stealing your money.

The TO address matches an address shown to your in wallet.

## Registration Period

Today the setup has a registration period for users, to lower the number of nullifiers they must download.

The new system has no registration period. We get around the nullifier download problem using PIR.

## Latency of voting

Today every vote has considerable latency, e.g. re-building the nullifier exclusion tree. I don't have concrete numbers, but each operation is considerably blocking.

In shielded vote:

* Register takes \~30s, but is backgrounded
* Each vote ZKP also takes \~15s, but is also backgrounded

So you can concurrently place all your votes, with an additional 15s of overhead.

We don't need user mobile wallets to do shielded sync per vote, as the delegation software is not intended for the mobile wallet. Mobile wallets only need to perform a sync to update their VAN inclusion proof heights.

## Vote amount privacy

**Today:**

Today votes are encrypted to a key shared by the entire election authority

**Shielded Vote:**

In shielded vote, votes are also encrypted to a key shared by the entire election authority. Each vote is encrypted and summed in a unique accumulator for (proposal id, decision)

However, the user's vote is split into multiple vote amount placements, that are cryptographically unlinkable. Thus if the EA was malicious, they would see on-chain unlinkable votes for smaller amounts. We still face timing correlations + usage concerns, that could lead to linking in such a case.

The share submission servers' job is to help reduce the timing correlation, by completing the final ZKP on your behalf, and delaying its submission to the chain.

The current ceremony uses a trusted dealer — one validator generates `ea_sk` and distributes it to all validators via ECIES encryption. This means every validator can decrypt, limiting the damage of a single malicious EA. Long term, this should become a DKG (distributed key generation) where no single party ever holds the full `ea_sk`.

## Auditing the Tally

**Today:**

Today, the tally is not auditable. The election authority could just lie, and we trust them to not.

**Shielded Vote:**

Due to using el-gamal votes, every full node can publicly sum the on-chain el-gamal ciphertexts. Then when the election authority decrypts, they provide a simple proof of valid decryption of this aggregated ciphertext.

Thus everyone can publicly audit this.

## Nullifier Privacy

In today and in shielded vote its the same