-
Notifications
You must be signed in to change notification settings - Fork 0
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
[Group Formation] Token User Experience Working Group #1
Comments
Very happy to see these methods evolving. Even just getting more prior art in the ecosystem for this kind of thing is great. Extra InspirationVery curious at which points these different feature-specific message types can start to standardize around common formats. Happy to watch the gradual evolution, but it's no secret that I think these should and will tend towards becoming a generalized object capability framework. When To MeetI can mostly only commit to times that are in the evening PST or on Fridays during the PST daytime. |
Very interested in discussing these things as well. Thanks for starting the thread.
|
We might want to start a multi-thesis kialo poll to find what our top priority target feature/requirements for a next iteration/standard might be. I like all those features, and I even have ways I'd like to extend them long term, and so the hardest decision (for me? for the community?) tends to be "what's the next valuable iteration?" A couple ways I can see for extending @julien51's ideas in a more general direction:
If we allow A quick shot at defining
If you wanted to embed these in an |
Yes! I love these topics :)
I want to break this down a little bit.
Are you imagining a
Is there an agreed upon standard for encoding signed messages that can be interpreted and ran by a smart contract? It sounds like you are describing a "mini on-chain interpreter" that uses encoded/minified signed messages to handle smart contract logic at run-time? I would like to see this approach more readily available in the ecosystem, because when we start to use signed messages as smart contract logic gateways, it opens interesting opportunities (I think) for possibly introducing verifiable credentials as another method for adding real world state to on-chain logic i.e. another oracle method. If messaging signing Proxies can also get authority from an on-chain PKI protocol (with @SilentCicero weighted signatures experiment too), this in short grants users permissions to specific smart contracts functionality via delegated signed messages, via on-chain This could unlocks token mechanics (and other permissions) at an organizational level and NOT just the user key or on-chain wallet. Maybe? We recently experimented with a very simple condensing method. Condensing signatures and batch processing them. @joeb000 can speak more to it, since he implemented the contracts. However, it is very specific to our forked ERC20, which we call ERC20Certificates that basically allows us to issue IOU's and have the user redeem the token, without us transferring and incurring gas costs. The approach wouldn't apply to existing tokens and would need to be backported in a "wrapper" smart contract, which we call https://github.com/rapid-eth/erc20-certificates/blob/master/contracts/ERC20Certificate.sol#L94
That makes a ton of sense! And I think we're starting to see this hardened business requirement around DeFi applications that need those predictable transactions for coordinating across the many new composable finance protocols.
Can we discuss a little further on how we want to implement this? I know serial, atomic transactions can be executed, but I think that's my least familiarity in this current scope, especially when doing it via signed messages and not relying on the EVM to coordinate tx stuff more natively. Is there something we can utilize now? Or do we need to fork and abstract an existing smart contract? Also I wan to add @SilentCicero to the conversation, because he recently was explaining to me how he wants to do a |
A little bit on a side topic as per the direction is currently going in- the same way there is a standard for MetaData for TokenURI's, we should create a standard for the data about counterfactual tokens. IE when I create a counterfactual token series and store the root on-chain, I should then also be able to store the JSON object that represents the tree of counterfactual tokens so that services like OpenSea can index counterfactual tokens the same as "minted" tokens, with the exception of course they need to be minted to become tradable. |
@crazyrabbitLTC interesting. I would have assumed a standard of some sort was already underway. Counter factual assets make a lot of sense for user experience I think too. I like how Pepo is incorporating optimistic UI in there app when it comes to tokens. Worth checking out. I think if we use counterfactual assets in a smart way we can include more optimistic interface improvements too. Let's experiment :) Dan is right though we need to take a poll of some sort so we can identify the multiple optimizations that we are all talking about in this thread. There is meta transactions, counterfactual assets, signature authentication methods and perhaps whatever else we come up with. What do you guys think? Does it make sense to discuss all of those topics on this ticket or should we make new tickets or do we create a keybase chat group to discuss these more in real time? |
No, contract accounts like Gnosis safe already have support for batched transactions, and it results in improved gas performance, among achieving batched atomicity, and probably other benefits. In the spirit of Like I said in tweet with you, add metaTx to contract accounts, and those users can use metaTx on all contracts. Add metaTx to contracts, and all their users can use metaTx. There are benefits to both cases.
I don't believe there currently is a standard for signed messages intended to be run by a smart contract, and this would be a wonderful target for anyone involved in MetaTransactions, because once there is one, wallets could interpret the signing of these messages with the same interpretation they render transactions with. Combined with batching, and several messages could be authorized with a single signature, which could reduce gas costs, and be used to compose metaTx paybacks quite naturally (you can include a gas-paying message in the queue).
I strongly believe delegation is a pattern that works at basically every scale, from the individual, to the organization, all the way down to the nanoprocess.
Same for Also, I don't think you need to "wrap"/lock a token to allow its delegation: You could use the
Since any solidity can call
I think we've already begun to stretch what a single-threaded github issue can gracefully manage, there are a lot of incrementally deliverable specs of value here (like a standard signed invocation message standard) that could be built into the other things we've discussed. |
Sorry. I should have been more explicit. Sooo many ideas rattling around :) To clarify I totally agree with you, that a "exploring protocols that could be added to smart contracts " should be a top priority. That being said, I think for me at-least it's interesting to think about how to use existing audited contracts to get an MVP for some optimizations today. I know Like @julien51 pointed out certain token distribution systems can be optimized due to the shared contract factory. Maybe I'm wrong but a SmartContract interface that utilizes the existing multi-sig features +++ these new signatures standard in a module, seems like the most optimal way to help achieve that prototype. Happy to be proven wrong, because I know there are probably sooo many ways to skin that cat? Perhaps we need to separate technical and product level discussions, for clarity sake, but ensure we think of both, so we move into the future, but also help others upgrade existing systems. I really want Nick to hop in here, because he was explaining something close to what I think we're grasping at here, which was using weighted signatures to "brute force" a `multi-sig' module system.
This should definitely be a bigger ecosystem conversation. I like your idea of Ethereum Magicians.
Again I agree with you that atomic transactions should be first priority 😊 In addition though I would also like to see procedural approach too. Where transactions can be coordinated across multiple blocks and... this is where my head starts to spin... transactions in ETH 2.0 in multiple shards 🤯🤯🤯 I think that optimization will be interesting for DeFi protocols that need atomic swaps, but ALSO wan't procedural contracts for better user experience with smart wallets. SidenoteHave to go hop on train to NY, but will continue to think about next steps. I think Keybase and Ethereum Magicians sounds like the way to go. Should we just pull trigger on those? |
I think that's an interesting idea, and it might be worth breaking the whole gnosis-safe module system into an extensibility pattern that can be added to any contract, so that modules like this can be added to them. It's worth highlighting that this kind of extensibility requires explicit governance of that contract, so I'm sure it won't appeal to all contract authors, but for groups that have a well-defined upgrade path already, I don't see why they wouldn't, and so packaging any of these proposals as a
I think my view of multi-shard atomicity found clarity in this talk, which basically suggests for atomicity you need the operation to take place in a single process, and you can achieve this effect by moving transfer rights from multiple shards/chains into a single permitted environment which then performs the atomic interaction. For the sake of simplicity, I think we can constrain the batch processing to interactions that are atomic within the current synchronous context. The only thing holding me back on the keybase team is a catchy name. "Token user experience working group" is a mouthful, and a bit more specific than I'm thinking ;)... Not a huge rush, though. Happy to stew on that before doing it. |
A proposed bounty for the upcoming Gitcoin hackathon: https://medium.com/@danfinlay/announcing-a-the-generalized-metatransaction-contest-abd4f321470b (Draft, soliciting feedback) |
We're making a bounty of this in Gitcoin's virtual hackathon starting tomorrow morning: |
@danfinlay That's awesome! I have let my team know. We definitely want to contribute to this effort and will start discussing immediately ways we can help bring this to life. |
Thanks for this initiative @danfinlay Excited to be contributing towards this generalized standard for meta transactions. |
@kamescg Hey! Wanted to add to your list of resources a free course on Meta-Transactions from Academy with help from Austin Griffith, Alex van de Sande, OpenZeppelin and Simona Pop: |
Wrote this last week https://medium.com/bloxis/generalised-ethereum-meta-transactions-our-take-cb9f027866e9 - just want to be a part of the conversation and build something great. Is the group already having meetings?? |
Token User Experience Working Group
Objective: Optimize user experience for ERC20 and ERC721.
User experience includes minimal transactions/signing and also lower gas costs.
Meeting Schedule
To be determined.
Overview
Transferring tokens from accounts (funded and unfunded) should be easier for all users.
The new
permit
function included inSAI
is a great demonstration of the added benefit of using signatures, in addition to transaction to unlock smart contract functionality. Minimizing user friction.In addition to the current upgrade in the DAI contract we can also backport that functionality to existing ERC20 contracts. A number of solutions can be proposed and utilized. It would be great to define and prototype a few really good working examples.
@joeb000 has been experimenting with similar signing token transfer setups.
https://github.com/rapid-eth/erc20-lockbox
Meta Transactions
Ref1: https://twitter.com/austingriffith/status/1196470765350113281
Ref2: https://twitter.com/UnlockProtocol/status/1196886794094219265
Ref3: https://twitter.com/KamesCG/status/1194853820326653952
Merkle Trees
Ref1: https://twitter.com/DennisonBertram/status/1196898372365488128
The text was updated successfully, but these errors were encountered: