Type safe address api #491
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ccjernigan
reviewed
Aug 23, 2022
nuttycom
force-pushed
the
feature/zip-316-and-latest-upstream
branch
from
e348740 to
905ee40
Compare
pacu
force-pushed
the
type_safe_address_api
branch
from
6290dcf to
ed2dc40
Compare
|
@str4d @nuttycom I updated the code to this branch that builds https://github.com/zcash-hackworks/zcash-light-client-ffi/tree/bin/librustzcash_0_7 Some of the tests to derive keys fail. Also it appears that key validation functions don't produce errors when the key is semantically correct but belongs to a different network |
nuttycom
reviewed
Aug 29, 2022
Sources/ZcashLightClientKit/Block/Processor/CompactBlockProcessor.swift
Outdated
Show resolved
Hide resolved
Sources/ZcashLightClientKit/Block/Processor/CompactBlockProcessor.swift
Outdated
Show resolved
Hide resolved
nuttycom
approved these changes
Aug 29, 2022
This was referenced Aug 29, 2022
LukasKorba
reviewed
Sep 1, 2022
Example/ZcashLightClientSample/ZcashLightClientSample/Send/SendViewController.swift
Show resolved
Hide resolved
LukasKorba
reviewed
Sep 1, 2022
Sources/ZcashLightClientKit/Transaction/WalletTransactionEncoder.swift
Outdated
Show resolved
Hide resolved
LukasKorba
approved these changes
Sep 1, 2022
This PR creates data types for Addresses and Keys so that they are
not represented by Strings anymore. This avoids mistakenly use
the wrong keys because they are all alike for the type system.
New Protocols:
=============
StringEncoded -> Protocol that makes a type can be expressed in an
string-encoded fashion either for UI or Interchange purposes.
Undescribable -> A protocol that implements methods that override default
decriptions used by debuggers, loggers and event trackers to avoid types
conforming to it to be leaked to logs.
Deleted Protocols:
==================
UnifiedFullViewingKey --> turned into a struct.
UnifiedAddress --> turned into a struct
new Error Type:
================
````
enum KeyEncodingError: Error {
case invalidEncoding
}
````
This error is thrown when an Address or Key type (addresses are public
keys in the end) can be decoded from their String representation,
typically upon initialization from a User input.
New Types:
=========
SaplingExtendedSpendingKey -> Type for Sapling Extended Full Viewing Keys
this type will be replaced with Unified Spending Keys soon.
SaplingExtendedFullViewingKey -> Extended Full Viewing Key for Sapling.
Maintains existing funcionality. Will be probably deprecated in favor of
UFVK.
TransparentAccountPrivKey -> Private key for transparent account. Used
only for shielding operations. Note: this will probably be deprecated soon.
UnifiedFullViewingKey -> Replaces the protocol that had the same name.
TransparentAddress -> Replaces a type alias with a struct
SaplingAddress --> Represents a Sapling receiver address. Comonly called zAddress. This address corresponds to the Zcash Sapling shielded pool.
Although this it is fully functional, we encourage developers to
choose `UnifiedAddress` before Sapling or Transparent ones.
UnifiedAddress -> Represents a UA. String-encodable and Equatable. Use of
UAs must be favored instead of individual receivers for different pools.
This type can't be decomposed into their Receiver types yet.
Recipient -> This represents all valid receiver types to be used as
inputs for outgoing transactions.
````
public enum Recipient: Equatable, StringEncoded {
case transparent(TransparentAddress)
case sapling(SaplingAddress)
case unified(UnifiedAddress)
````
The wrapped concrete receiver is a valid receiver type.
Deleted Type Aliases:
=====================
The following aliases were deleted and turned into types
````
public typealias TransparentAddress = String
public typealias SaplingShieldedAddress = String
````
Changes to Derivation Tool
==========================
DerivationTool has been changed to accomodate this new types and
remove Strings whenever possible.
Changes to Synchronizer and CompactBlockProcessor
=================================================
Accordingly these to components have been modified to accept the
new types intead of strings when possible.
Changes to Demo App
===================
The demo App has been patch to compile and work with the new types.
Developers must consider that the use (and abuse) of forced_try and
forced unwrapping is a "license" that maintainers are using for the
sake of brevity. We consider that clients of this SDK do know how to
handle Errors and Optional and it is not the objective of the demo
code to show good practices on those matters.
Closes #461
pacu
force-pushed
the
type_safe_address_api
branch
from
666b287 to
ed87a27
Compare
nuttycom
requested changes
Sep 6, 2022
unified address from SDK Synchronizer
…Char](key.utf8CString)`
nuttycom
reviewed
Sep 6, 2022
Closed
Closed
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #461
Closes #510
Closes #517
This code review checklist is intended to serve as a starting point for the author and reviewer, although it may not be appropriate for all types of changes (e.g. fixing a spelling typo in documentation). For more in-depth discussion of how we think about code review, please see Code Review Guidelines.
Author
Reviewer