With all due respect, I think you’re directing that criticism at the wrong person.
It wasn’t me who introduced a confrontational tone into this thread… it was one of your subordinates:
I’m not sure if you consider that tone acceptable, but I’d argue it’s far more inflammatory than anything I’ve said. My responses have been direct, sure -maybe even a little snarky- but I’ve avoided insults, personal attacks, or dismissing anyone’s arguments out of hand.
If you’re going to moderate tone, then please make sure it applies consistently, regardless of whether the person in question reports to you or not.
That said, I’d honestly prefer if we moved past the tone policing and got back to what actually matters here: the substance of the discussion.
I my next sentence I was asking for your concrete feedback. You conveniently leave that out and latch onto a sentence in order to accuse me of sitting in some ivory tower. I am doing as much as I can to deliver a useful product. I am thinking about how it will be used every day. But without actually building that myself it will always be an incomplete picture. Hence the ask for feedback.
I don’t get the feeling you are arguing in good faith here. This takes too much of my energy without gaining any useful insight. Consider this my last post here.
To get back to the initial topic of this thread, I had this idea some time ago. This would basically achieve what you are asking for. Chaining of transactions and passing information from one call to another.
I have the feeling that trying to use contracts to solve this is just a bad hack that will not make it better.
There is not much info outside of original issue but I think this could be solved in a generic way. XCM already has wildcards for tokens. Ethereum allows to consume outputs by default. Could we perhaps enhance substrate in more generic way to allow interop between pallets or contracts code in a similar way?
I will skip to the last message as the issues like logs, tooling, indexers, precompiles was mostly covered and with the last message from @josep propose to deploy aave and curve instead of Uniswap. Uniswap is too simple to find all the issues that will come with deploying EVM (often flawed but now standardized) code to Polkadot. In aave you will see how to cross integrate non-transferrable tokens, rebasing tokens and bunch of other primitives which work completely differently than anything in Polkadot world and then make it work with XCM. This would be good test for this readiness.
To the other points around the precompiles, I also think that just exporting a few precompiles will not make a difference. While I get that precompiles need to be stable and can not change, I think exposing one precompile that is unstable by nature could may be an interesting idea. This precompile could just allow to dispatch a call. Such a contract would may break, but it could be used as a testing ground to find out about possible future precompiles.
It has become a general pattern of yours to be unnecessary aggressive, across all the forums.
Parity and co are delivering well with their current capacity.
And as Alex already pointed out, things can be said in a constructive and professional manner without sounding rogue. I get the frustrations but this is weird way of communicating and that too in a public forum.
PS. I have had the chance to speak with Josep and also other Parity teams in person and I feel like there is unnecessary misunderstanding and heat going on.
We all want to make this successful and pointing out the problems before they happen is way better than doing nothing and then bitching that stuff doesn’t work. I believe it’s very valuable to have this discussion now and focus on the points instead of trying to take this personally. It is a big task and it will require all hands from everywhere to give their 5 cents and helping hands to make it a success. I believe everybody here is on the same team.
Yes! When I first started thinking about how to solve this issue, I came up with a very similar idea. So it’s really encouraging to see you’ve been exploring the same direction.
That said, I kinda disregarded this b/c getting proper tooling support for it won’t be easy… also, I suspect the DX might feel a little hacky. But honestly, I’m 100% on board with giving it a shot. Thanks a lot for trying to find a pragmatic solution
Of course, this kind of approach would only unlock fairly basic flows. You’d still be limited, e.g., you couldn’t switch execution paths conditionally. Not to mention that many calls don’t emit events for all the state changes, and sometimes you’d really need a storage read. But in the absence of custom contract logic, this would still be a nice improvement over what’s currently possible.
Totally agreed.
My main point was more about starting with the basics: nail the minimal path, validate the core hypothesis, then consider expanding from there. You won’t uncover the real DX and compatibility pitfalls until you actually try porting and running these projects on Westend AH. Whether it’s Uniswap, Aave, or something else, the idea is: get real-world software running ASAP.
That’s the only way you’ll get meaningful feedback and validate the whole approach.
Exactly! This ^
We deal with runtime upgrades all the time, if a contract breaks with a new runtime, I’ll just deploy a new one that works with the new logic. It’s not ideal, sure, but it’s way better than being stuck with nothing because we’re afraid of breaking changes.
I totally get the need to offer strong guarantees for asset-related contracts. I also think those should be rock solid. But that shouldn’t prevent devs from deploying “unstable” contracts that tap into more dynamic or experimental parts of the runtime.
Let the ecosystem evolve with both:
Stable, minimal precompiles for standardized, composable building blocks.
Unstable, experimental precompiles as a testing ground for future capabilities.
