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

Should "one round trip" be a design goal? #13

Open
snario opened this Issue Nov 4, 2018 · 2 comments

Comments

Projects
None yet
3 participants
@snario
Copy link
Member

snario commented Nov 4, 2018

There is a tradeoff between complexity and communication overhead for which we've opted in favor of optimizing the latter. There are good points about why complexity is an equally and potentially more important design goal that I'd like to encourage us to record our thoughts about here.

NOTE: There have already been a handful of discussions in person.

@snario snario added the discussion label Nov 4, 2018

@armaniferrante

This comment has been minimized.

Copy link
Collaborator

armaniferrante commented Nov 4, 2018

If my memory serves me correctly, the motivation for "one round trip" was not really the "round trip" in terms of latency. It was "one api call" from the perspective of an application

This discussion started when the "worlds" api was still around, where it was the application's job to trigger each step of the protocol. With that programming model, "one api call" was desirable because it simplified the application code. However, in the world of the machine, this doesn't necessarily apply, because the machine drives the protocol execution.

In other words, I don't think the "one round trip" goal really applies anymore because the design of the system changed from this question's original motivation.

If we're talking in terms of latency, what is the max number of round trips we can expect? Probably not more than 2? Maybe 3? An extra round trip is going to be <= 150 ms. If there are two then <= 300 ms (also we can really cut those upper bounds in half since the message just needs to go one way to trigger the next step of the protocol). And so, I don't think constraining to one round trip is a huge performance concern. I would choose minimizing complexity in this instance.

@emansipater

This comment has been minimized.

Copy link
Member

emansipater commented Nov 5, 2018

Intuitively to me it seems that we can "have our cake and eat it too" if we find the right abstract metaphor for the single round trip construction. Given that latency reduction is the key advantage of state channels in the first place I am hesitant to double or triple that latency unnecessarily.

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