Skip to content
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

optimization of registry #41

Closed
astroseger opened this issue Sep 28, 2018 · 2 comments
Closed

optimization of registry #41

astroseger opened this issue Sep 28, 2018 · 2 comments
Assignees

Comments

@astroseger
Copy link
Collaborator

Registry is very gas-expensive, for example addTagsToServiceRegistration costs > 600.000 gas!!. After betta we should try to optimize it.

@astroseger astroseger assigned astroseger and unassigned astroseger Sep 28, 2018
@astroseger astroseger changed the title optimization of gas consumption of Registry (post betta issue) optimization of gas consumption (post betta issue) Sep 28, 2018
@astroseger astroseger changed the title optimization of gas consumption (post betta issue) optimization of gas consumption for registry Oct 2, 2018
@astroseger
Copy link
Collaborator Author

astroseger commented Oct 2, 2018

We had the following conversation on slack (https://snet.slack.com/messages/CCDKDJNUU/team/UA7QTHFS6/)

sergey:
(proposition 2: optimize registry with a standard IPFS trick)
The current registry is quite expensive in terms of gas (~600.000 gas ~= 2$ for add tag to service). Of course it should be optimize, and it is obvious without me saying it (we also should try to optimize MPE as well). But I want to propose to consider a different optimization strategy, which is seems quite standart now. We could move all information which is not directly required for on-chain logic to IPFS, as we are doing with Agent now (and keep only IPFS address on-chain). For example tags certainly could be moved off-chain. I could experiment with it later
cassio:
On registry vs IPFS: placing tags in the registry is motivated by the idea that anyone can then fairly easily search for those tags. This is a very poor man’s input for matchmaking agents and agents searching other agents autonomously.
That’s the historical motivation, but the current implementation does a poor job of living up to it, IMO.
I would be ok with the move to IPFS, but I’m not sure if that’s a good use of developer time right now. On the one hand, the requirements for matchmaking, the reputation system, offer nets and prototype work for agents that search for agents all will take place next year, and should radically alter how the registry looks from that perspective. On the other hand, your idea seems rather straightforward and gives us a better beta, so perhaps we should just go for it and worry about the long term requirements later.

@astroseger astroseger changed the title optimization of gas consumption for registry optimization of registry Oct 2, 2018
@astroseger astroseger self-assigned this Oct 2, 2018
@astroseger
Copy link
Collaborator Author

discussion was moved to #66

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant