Skip to content
This repository has been archived by the owner on Oct 25, 2024. It is now read-only.

Design and implement multi-tx loans #26

Open
Ruteri opened this issue Dec 12, 2022 · 3 comments
Open

Design and implement multi-tx loans #26

Ruteri opened this issue Dec 12, 2022 · 3 comments
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed

Comments

@Ruteri
Copy link
Collaborator

Ruteri commented Dec 12, 2022

Rationale

The feature would be a great tool for the searchers without access to huge upfront capital. It would help bring the leverage the big players have to the people.

Implementation

Looking at currently existing interfaces (ex http://flashbuilder.org/), the call is similar in spirit to bundles, and includes an additional parameter loanTo, that the builder loans its funds to for the duration of the bundle.
Could be implemented as a new call and bundle type, or it could extend existing structure with an optional parameter.

@Ruteri Ruteri added enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed labels Dec 12, 2022
@dmarzzz
Copy link
Member

dmarzzz commented Dec 12, 2022

I found some previous discussion around multi-tx flash loans and it seems that the main concerns of miner swapping out coinbase addr's are relieved via blinded beacon blocks. But I believe there are still concerns around a reorg? My initial thought was that might be okay as long as the total loan amount is less than some cap, but I need to dig into reorgs on beacon chain some more.

@bertmiller
Copy link
Member

Seems dangerous to do in the presence of short-term reorgs. But I'm open to supporting this feature on the builder if there is demand and perhaps we can just let builders toggle it on or off. Perhaps you could make this 0 risk at the end of an epoch too?

@Ruteri
Copy link
Collaborator Author

Ruteri commented Dec 13, 2022

A loose idea: would checking the timestamp shield the loaner from reorgs? The block timestamp post merge is deterministic and a missed or reorged out block would still make the timestamp increase.
Won't help with same-slot shenanigans, but if done through PBS the proposer would need to propose two blocks for the same slot, getting slashed in the process.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants