-
Notifications
You must be signed in to change notification settings - Fork 11.3k
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
Update tutorials.md #848
Update tutorials.md #848
Conversation
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.
I made a few suggestions and will try to conduct a thorough edit after you merge this.
doc/src/explore/tutorials.md
Outdated
4. (2) and (3) repeats until game ends. | ||
Because the admin owns the gameboard, each individual player cannot place a marker directly to the gameboard (they don't own the object, and hence cannot mutate it, see [Object Model](../build/objects.md)), each marker placement is split to 2 steps, that each player first sends a marker, and then the admin places the marker. A sample gameplay can also be found in the [TicTacToeTests](../../../sui_programmability/examples/games/tests/TicTacToeTests.move). | ||
Because the admin owns the gameboard, each individual player cannot place a mark directly to the gameboard (they don't own the object, and hence cannot mutate it, see [Object Model](../build/objects.md)), each mark placement is split to 2 steps, that each player first sends a mark, and then the admin places the mark. A sample gameplay can also be found in the [TicTacToeTests](../../../sui_programmability/examples/games/tests/TicTacToeTests.move). |
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.
I will edit this point directly. Lot going on here. :-)
Thanks, Xun. I will edit in toto later. |
A few edits
5026ec9
to
07f3a55
Compare
…ystenLabs#993) Today, the BlockSynchronizer receives several types of messages from the PrimaryReceiverHandler, which go on a different channel depending on their nature. This does not scale, especially since we are about to add more messages types traveling the same component edge in MystenLabs#848. We put the messages under an enum and transmit that enum along the channel, which simplified BlockSynchronizer setup and channel patterns overall.
…tarting round (MystenLabs#848) Part 1/n of MystenLabs#740 This PR adds logic to `BlockSynchronizer` to broadcast a request to fetch certificate digests with a starting round, and collect valid certificate digests from the received responses. High level overview of the algorithm (as discussed with @huitseeker): 1. When a primary needs to sync a range of certificates, it first finds the last round of certificate it has. Then it broadcasts a requests to synchronize certificate from higher rounds (last round + 1). 2. Other primaries / authorities will reply with certificate digests at or above the requested round (to be implemented later). 3. The requesting primary will collect the responses until heard from all, or timeout. Then, certificate digests having collected stakes above the committee validity threshold (f + 1 stake) are considered valid. Valid digests are returned. Notably, this PR does not contain the logic to handle the range sync request on primary, or the logic to drive fetching certificates based on the valid digests. A unit test is added for the happy path.
A few edits