-
Notifications
You must be signed in to change notification settings - Fork 206
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
feat(cosmic-swingset): use a fake chain for scenario3 #322
Conversation
ced81b9
to
854a7b0
Compare
Looks like this needs to be rebased onto current trunk: the |
Done.
@warner, Do you mean "into their own PR"? If so, I've now reverted the SwingSet changes and can create an issue and PR for the other (minor) SwingSet change. |
This introduces block latency so that the scenario3 chain behaves much more like a real blockchain, but within the same process (for debuggability) and without the actual Cosmos SDK usage.
c06b378
to
492f242
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@michaelfig and I walked through this today.. I think it's ok to land. I'm a little worried about the technical debt incurred by layering this on top of the existing scenario3, but the functionality is compelling, and we're planning to refactor all of this soon in the agoric-cli
package.
Before this change, "scenario 2" meant two processes. The first used cosmos-sdk and a swingset embedded in the chain that held the "central-services" vats. The second used ag-solo with a swingset that held the "client-side" vats and speaks http to the frontend. "scenario 3" meant one process (with one swingset, holding both central-services and client-side vats, speaking http to the frontend, and no cosmos-sdk or golang anywhere).
With this change, "scenario3" means one process with two embedded swingset kernels (one for central-services, one for client-side), which communicate to each other through a mailbox (on a delay).
Let's put a note to that effect in the Makefile to remind us how this works/worked.
Another thought we had was to retain at least the notes about how start what used to be scenario3. It's not worth creating a "scenario4" to hold it, but let's cut-and-paste-and-comment-out the scenario3 rules for the benefit of teaching us something in the future.
Finally, maybe consider removing the empty scenario3-run-chain
target, and renaming the remaining one something like scenario3-run
. We only have one process, so we only need one run
command, and I think the false parallelism with the two-process scenario1/2 cases isn't super helpful. Or maybe it just interferes with my tab-completion (when I type make sc TAB 3-ru TAB
, I get stuck with make scenario3-run-c
instead of completing all the way to the one useful value: make scenario3-run-client
)
Make a `deprecated-scenario3-setup` and `deprecated-scenario3-run-client` to illustrate the old scenario3. Create `scenario3-run` to make tab-completion better.
* feat(cosmic-swingset): use a fake chain for scenario3 This introduces block latency so that the scenario3 chain behaves much more like a real blockchain, but within the same process (for debuggability) and without the actual Cosmos SDK usage. * fix(Makefile): refine rules Make a `deprecated-scenario3-setup` and `deprecated-scenario3-run-client` to illustrate the old scenario3. Create `scenario3-run` to make tab-completion better. * doc(README): remove Golang prerequisite: no longer needed
This introduces block latency so that the scenario3 chain
behaves much more like a real blockchain, but within the
same process (for debuggability) and without the
actual Cosmos SDK usage.
Closes #321