-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PERA-1348 :: Add in architecture related ER diagrams designed in mermaid #92
Conversation
c63256b
to
fc92e96
Compare
String seed_custom_name | ||
} | ||
hd_keys { | ||
String encrypted_address PK |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@michaeltchuang @mitsinsar Lets not use address, but public keys
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lets also avoid strings and any encoding to store raw public keys. Bytes :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@michaeltchuang @mitsinsar Lets not use address, but public keys
@ehanoc I actually had public_key
as PK at first for hd_keys
table...but I realized when we fetch/delete through Pera UI or deeplink, user may want to do this by algorand address...so I think algorand address should be a column in table. Is it easy to go algorand address -> public key
? If so, then maybe I can create a mapper back/forth.
@yigitguler are you back this week? Did you want to weigh in what you think should be stored and what should be derived runtime?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated the PR now so hd code/schema is using public keys and algorand addresses are derived runtime
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@michaeltchuang Algorand address can be seen as a denormalized field in the table. IMO, it is ok to keep the Algorand address in the table as well, only if it brings significant performance optimization.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In a scenario where the user has 100 accounts (I know it is above our current limits) How much computation time does it require to get the algorand address from the public key? If it is really fast, maybe we can just store the public key and prepare some utility functions to lookup the account with the algorand address.
712006e
to
335dff8
Compare
49c3a59
to
461818c
Compare
String entropy_custom_name | ||
} | ||
hd_addresses { | ||
String encrypted_address PK |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@michaeltchuang Why encrypted address & public key? there's zero risk and adds extra steps at no gain.
Pull Request Template
Description
Related Issues
Checklist
Additional Notes