Announcing Halo ARC

Electric Coin Co. (ECC) today announced Halo Arc for Zcash, a product suite to launch the next generation of Zcash. It includes updates to Zcashd, the ECC Reference Wallet apps and the ECC wallet SDKs.

Halo Arc leverages two upcoming Zcash improvements: Network Upgrade 5 (NU5) and unified addresses. NU5 will move Zcash to the Halo proving system, representing the continual evolution of our zk-SNARK technology stack. Halo removes the need for the trusted setup and upgrades the protocol’s underlying cryptography.

Unified addresses, a complementary feature, introduce a future-proof address format that prioritizes shielded adoption. Later this week, we’ll release a blog post with a deeper explanation of unified addresses, how they work and what it means for supporting Zcash users to shield by default.

The planned release of Halo Arc is Oct. 1, 2021*, to coincide with the activation of Network Upgrade 5 (NU5)**. NU5 will be the first mainnet activation of the Halo proving system, marking a significant achievement in the evolution of zero knowledge proof cryptography.

The Halo Arc product suite includes:

  • ZCASHD, NU5-COMPATIBLE CONSENSUS NODE: Zcashd is the consensus node for Zcash. Zcashd will support the upcoming network upgrade, which includes the Orchard Shielded Protocol (ZIP 224), non-malleable transaction IDs (ZIP 244), a new transaction version format (ZIP 225), and unified addresses (ZIP 316).
  • ECC REFERENCE WALLET (iOS and Android): ECC Reference Wallet is a beta reference implementation of a Zcash wallet for Android and iOS, available as open source.
  • NU5-COMPATIBLE WALLET SDKS: ECC maintains wallet SDKs for Android and iOS. These SDKs will support the upcoming network upgrade, including a new transaction format, the Orchard shielded pool and unified addresses.
  • AUTO-SHIELDING FEATURE: Auto-shielding lets users (more specifically their wallets) automatically move funds from a transparent address to the latest shielded ZEC pool. Auto-shielding, along with unified addresses, will facilitate increased user privacy and a better overall user experience. Through auto-shielding, wallets can offer their users funds that are shielded by default, regardless of the originating address.
  • AUTO-MIGRATION FEATURE: Auto-migration is a mechanism for wallets to seamlessly move funds to the most modern shielded pool supported by the wallet. This feature will also make it easier to deprecate older pools.
  • IMPROVED NOTE MANAGEMENT: Improved note management reduces the time users need to wait between sending transactions. This means that lightclients will be able to send one transaction immediately after another.

Halo Arc represents a new ECC strategy, which bundles upgrades, products and features into regular releases. These bundles could include any or all of the products that ECC develops, such as Zcashd, Lightwalletd, wallet SDKs, and wallet source code.

As Zcash development decentralizes, the broader Zcash community will benefit from a greater diversity of products, such as the Zebrad consensus node from the Zcash Foundation and lightclient infrastructure funded by ZOMG. By emphasizing products as well as the underlying protocol, ECC can package and promote compatible software across the Zcash technology stack, from protocol to wallets.

17 Likes

Excellent, looks like a lot of important improvements are on the way

1 Like

What user facing improvement do you see? That part is not clear to me.

The UAs seem to be a nice user experience improvement. If I understand correctly, they will send shielded and receive shielded by default.
No need for the user to select which address to use in his wallet since it will be handled automatically.

Well, if there was no upgrade, you wouldn’t need this since the current zs address do that. The problem it solves is due to the various value pools (sprout, sapling, orchard,…) that current use different addressing schemes. Sure it is nice to have a solution but the users expect it.

1 Like

Sure, but that implies you already chose the zs address as a user instead of a t address. It is an easy and straightforward choice for many, but might not be for new users. (Again, that’s how I understood it, not 100% sure yet).

Same for UA, they are shielded. You chose them over t addr too.

Interesting, so UAs are shielded? I thought it was combining T&Z somehow…

I’m still a bit unclear as to how these UAs work,

Now we have:

  1. T address
  2. Z address Sprout
  3. Z address Sapling

After Halo we will have:

  1. T address
  2. Z address Sprout
  3. Z address Sapling
  4. Unified Address

Or is it:

  1. T address
  2. Unified Address

Or:

  1. Unified Address

:thinking::thinking:

1 Like

I’m not clear either. I understood they were shielded from the article:

“With Halo Arc, we’re making it easy for wallets to support shielded Zcash by default,” said Swihart. “Users of supporting wallets will be able to give counterparties a single address and know that funds will be sent to their shielded address, regardless of whether the sender supports shielded addresses.”

It seems it means

  1. T addr
  2. UA

???

We can still count sprout but I’d just substitute orchard addys in that list and also potentially UDA addys

A lot of the details of the Unified Addresses need to be figured out, especially by wallet developers like myself, but here’s some intuition to help the thinking around it.

Imagine that we define a Unified Address as simply a zcash URI. The URI is of the format:
zcash:<t-address>?alternate.sprout=<sprout address>&alternate.sapling=<sapling address>&alternate.orchard=<orchard address>

So, when a reciever’s wallet wants to display a Unified address, it constructs this URI, filling in all the address formats that it is capable of recieving. JAXX wallet might fill in just the <t-address>, while Zecwallet Desktop might fill in all taddr, sapling and orchard addresses and maybe Zecwallet Mobile will fill in only taddr and orchard address.

Then, when the sender’s wallet reads the Unified Address (which is just the zcash URI string), it can then figure out

  1. OK, the receiver can receive <t-address> and <sapling> types of transactions.
  2. I can send <t-address>, <sprout> and <sapling> types of transactions.
  3. I have funds in <orchard> and <sapling>

And then decide what type of transaction to construct and send.

This is not quite how it works, but it’s a helpful abstraction to think about how the Unified Addresses will work and how wallets will make use of them.

4 Likes

Does a zs to zo (orchard) bypass the turnstile or does it execute another or multiple aggregated txs like how auto shielding does now?

some extra info here:

I know now I’ll need the extra article to get a better idea of what it consists of :slight_smile:

That’s the intent. Taddrs are still necessary. But the UA should encapsulate all address types (including novel address types for interop and L2) and supplant shielded address. For Orchard and future pools, no native address will be available. It must go through a UA. We’re planning to post an explainer blog tomorrow morning.

4 Likes

@den Thanks for the link. It is very helpful.
@joshs From what I understand, future network upgrades will require a new UA for the user?

For example, let’s say there is a Sequoia upgrade. In order to have my current UA (sprout + sapling) include it as a recipient I will have to generate a new UA that has sprout + sapling + sequoia ?

Thanks

1 Like

Not necessarily. For example, Overwinter and Canopy did not require new address types. Orchard changes the underlying cryptography and requires a new pool, as did Sapling.

If a new pool is created, the wallet should be able to supply a UA that includes support of the new pool without a change to the address format, abstracting that complexity away from the user.

1 Like

But even if the address type is the same, wouldn’t you still need to indicate support in the UA if it is a different value pool?

And if the address type is different, you need to have a new UA, right?

Pool deprecation would necessitate it (blob of raw data under the UA header) needing modified as well and I think it was an automatic modification if the wallet indicates support but the ‘UA’ is/can be a permanent address (I believe).

I think it’s more like an “address pack”. The UA combines several legacy addresses together. But if there is a new type of address, it will not be covered. IMO, the term “universal” is a bit inaccurate as it implies future proof.
If you don’t upgrade your UA, you will not benefit from potential improvements in the crypto used by zcash.

I’m not super hip to automated control like that either but I think its the metadata that the address ‘string’ points to that changes (to my understanding). (“don’t upgrade your UA” I think is why Nathan expanded on explicit error handling because it wouldn’t be fullproof anyways (fixin Zookos triangle is hard!))