-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Abstract Coin/Coins and Accounts to be more general #79
Comments
That's very interesting! UIAs would be made much easier by abstracting out those two types. I found the basecoin plugin structure fairly rigid. I could be wrong about this but is it basically designed such that there's no entrypoint for code that isn't satisfying the interface? That's not really a negative mind you-- just trying to ensure I'm using all of this correctly. |
What's a UIA? How is the Basecoin plugin structure rigid? You have complete control over the application state through a plugin so you could do just about anything with it. Coins are needed per account in order to pay for tx fees... While I think we could abstract it out, there would have to be a good reason for it. There are benefits to standardization, such as the ability to use common logic for various applications. Or, out-of-the-box compatibility with the Cosmos Hub. Public blockchains need some kind of spam-prevention system. Abstraction isn't always desirable, nor is sticking to bad design. If we want something besides the Coins system, we need to assess the new design as it relates to the whole ecosystem. What's a concrete design that can replace the Coins system? |
@jaekwon hmm... you know what, I'm now thinking that coins are really just a subset of a higher level object which can be exchanged between accounts - if we built out the architecture for exchange of a more generic object type, then we would never need to abstract out coins but could build custom objects that work along side with coins, This way we keep the standardization as you pointed out, while allowing for expandability. I will have to ponder on what some of fundamentals of this generic object... Nonetheless I think this idea make a whole bunch more sense than abstracting coins... Thoughts? Also maybe accounts don't need to be abstracted either, maybe through using a []byte object we will be able to add in custom information for use within a plugin... I'd like to somehow be able to use the native accounts with customized information for plugins. good ideas here thanks for the feedback |
Absolutley. Compatiblity with the cosmos hub is why github.com/dawn-network/firstrays is how it is. Our goal is to build in the most standard way possible. Also-- about rate limiting, I agree there as well, and it is a tough nut to crack. Steem did rate limiting through a currency, of sorts that was called bandwidth and was awarded on the basis of non-spam transactions. So if someone was spamming, they would run out of bandwidth. Also, I had a look at web3.js. Tendermint (ethermint) chains are much better suited to its goals, IMO, because they are lighter, faster, and can be further optomized. It's interesting that web3.js exists-- when I called my writeup w3, I did not know that it did. I stopped following eth news when it was decided that they'd roll back the chain for the DAO. That was probably not the right move, but only hindsight is 20-20. @rigelrozanski - could you sketch out that object? |
Just a quick thought here: Tendermint is (can be used as) a library already. Might it be better to actually:
I think that this would make for a faster development process, because bootstrapping the network would be a zero-effort affair-- nodes could come up one by one and as long as the chain ID matched another node, they'd get paired. IMO, it would go a long way towards having TONS of TM chains that are all compatible with Cosmos. |
@faddat I'll post a concept plan here for a more generic object that encompasses the coin once I figure out all the basic elements it should include - haven't spent much time thinking about it yet, but let me know if you think of anything useful for such an object that you'd like to see |
@faddat How do we work on that together?
Sounds very cool. Are we creating algebraic types or what? Would love to see some examples. |
@rigelrozanski would love to see some more docs on this idea. Like 2 or 3 examples. I guess bonded tokens have a different logic than unbonded tokens. Is that what you mean here? Will try to integrate all these changes in my deeper refactor, which I label 0.7. Please add your ideas. |
@rigelrozanski I find the idea intriguing but have no idea how to solve this issue. Can you give some concrete examples that such a framework should solve and what it should look like? |
If there is nothing actionable here, I'm going to push this off from 0.7. When there is a concrete proposal, please re-open it. |
Add import/export of public keys cosmos#79
fix failure to persist vesting account
…g failures (cosmos#79) * fix: typo and wrong DKG infraction amount * fix: update default slashing beacon inactivity and dkg failure to zero
It would be nice to abstract out the types:
These two types could be re-implemented for specialized basecoin-plugins. For instance, maybe you want to turn the "coin" object into a smart-invoice that can get passed around with context for an expanded Account type.
Thoughts? Is there anything else that should be abstracted out while were on this train?
The text was updated successfully, but these errors were encountered: