Light Client TLA+ Specification #314

konnov · 2020-06-09T15:00:03Z

A TLA+ spec for the light client verification, in accordance with the English spec.

ancazamfir

Some initial comments on the Lightclient_A_1.tla model. I still have to look at the properties, load the mdel and try it. And also at the blockchain one.

ancazamfir · 2020-06-11T08:56:25Z

docs/spec/lightclient/Lightclient_A_1.tla

+
+ TODO: add a traceability tag as soon as the English spec has one
+ *)
+ValidAndVerifiedPre(trusted, untrusted) ==


I have some doubts about the name here and I know this is part of preconditions in the english spec. But imho this is not really a precondition. It should reflect what it does: given two headers, it checks that they are both within trusting period, > 2/3rds have signed the untrusted, etc. So it performs basic validation. I also don't see where the > 2/3rds check is done for the skipping case.

The naming is ok. It is just the precondition for ValidAndVerified.

Regarding, 2/3rds, good catch. We promoted the check to the general case, not only the non-skipping case.

ancazamfir · 2020-06-11T08:58:15Z

docs/spec/lightclient/Lightclient_A_1.tla

+  * Check that the commits in an untrusted block form 1/3 of the next validators
+  * in a trusted header.
+ *)
+OneThird(trusted, untrusted) ==


Maybe the name should reflect the meaning of the >1/3rd, i.e. the untrusted validator set should be trusted.

Suggested change

OneThird(trusted, untrusted) ==

TrustedValidatorSet(trusted, untrusted) ==

Renamed it to SignedByOneThirdOfTrusted

ancazamfir · 2020-06-11T08:58:27Z

docs/spec/lightclient/Lightclient_A_1.tla

+ValidAndVerified(trusted, untrusted) ==
+    IF ~ValidAndVerifiedPre(trusted, untrusted)
+    THEN "FAILED_VERIFICATION"
+    ELSE IF ~BC!InTrustingPeriod(untrusted.header)


Can we reach this? We are here with ValidAndVerifiedPre(trusted, untrusted) being TRUE that checked:

BC!InTrustingPeriod(trusted.header)

trusted.header.time <= untrusted.header.time

You are totally right! This is a good lemma :-)

We have added a comment like this:

(* We leave the following test for the documentation purposes. The implementation should do this test, as signature verification may be slow. In the TLA+ specification, ValidAndVerified happens in no time. *)

ancazamfir · 2020-06-11T09:00:34Z

docs/spec/lightclient/Lightclient_A_1.tla

+        /\ fetchedLightBlocks = [h \in {TRUSTED_HEIGHT} |-> trustedLightBlock]
+        \* initially, lightBlockStatus is a function of one element, i.e., TRUSTED_HEIGHT
+        /\ lightBlockStatus = [h \in {TRUSTED_HEIGHT} |-> "StateVerified"]
+        \* the latest verified block the the trusted block
+        /\ latestVerified = trustedLightBlock


Could all this be grouped in a single store record so it better reflects the code and english spec? Here is not too bad but it becomes harder to follow in the rest of the spec

I would prefer to keep the specification to the minimum. A record would introduce unnecessary detail here. One can also argue that LCInit encodes a method of the corresponding block store, so the variables are implicitly referenced with this ;-)

ancazamfir · 2020-06-11T09:03:26Z

docs/spec/lightclient/Lightclient_A_1.tla

+LightStoreGetInto(block, height) ==
+    block = fetchedLightBlocks[height]


I am curious why not return the block here.

Suggested change

LightStoreGetInto(block, height) ==

block = fetchedLightBlocks[height]

LightStoreBlock(height) ==

fetchedLightBlocks[height]

Same question for most of the other defs.

Good question. It looks like an artifact of an older spec. We just inlined it.

ancazamfir · 2020-06-11T09:53:09Z

docs/spec/lightclient/Lightclient_A_1.tla

+\* Check, whether newHeight is a possible next height for the light client.
+\*
+\* TODO: add a traceability tag when Josef adds it in the English spec
+ScheduleTo(newHeight, pNextHeight, pTargetHeight, pLatestVerified) ==


This is a predicate. Also I find it easier to read if the parameters reflect the height order

Suggested change

ScheduleTo(newHeight, pNextHeight, pTargetHeight, pLatestVerified) ==

CanScheduleTo(newHeight, pLatestVerified, pNextHeight, pTargetHeight) ==

This is incredibly hard to read, and I know in the english spec it is kept vague. I understand that we want to allow some flexibility on how we pick headers during bisection but in this model we can just take the half. Since the strategy doesn't affect correctness this should be fine. I also don't understand why it is called schedule. We do not schedule anything. Same in english spec. It is just a simple operation of selecting a new height.

In case we keep it this way, it might be easier if the caller decides whether to pick a header:

either between pLatestVerified and pNextHeight or

between pNextHeight and pTargetHeight
...and have something like:

Suggested change

ScheduleTo(newHeight, pNextHeight, pTargetHeight, pLatestVerified) ==

CanSchedule(newHeight, low, high) ==

Regarding the name, "schedule" comes from the Rust implementation, so we better keep it like that. Let's rename it to CanScheduleTo though.

For the responsibilities of the caller, it is better to keep the verified and block scheduler as independent from each other, as possible. Splitting the decision into two parts on two sides complicates the interface. The current version might be hard to read, but that is because it captures all possible block schedulers we may implement in the future. A concrete implementation of the scheduler should be more intuitive.

We have changed the parameter order. Your version makes more sense.

ancazamfir · 2020-06-11T10:07:28Z

docs/spec/lightclient/Lightclient_A_1.tla

+      \* the loop condition is true
+    /\ latestVerified.header.height < TARGET_HEIGHT
+      \* pick a light block, which will be constrained later
+    /\ \E current \in BC!LightBlocks:


This is a bit confusing. We pick any block from the blockchain only to immediately overwrite it with the block with nextHeight either from the light store or from chain. Can we remove this line altogether?

We pick any block from the blockchain only to immediately overwrite

Here is the place where TLA+ differs from a programming language. In a model checker like TLC, all blocks will be enumerated and then the blocks that do not match the constraint will be rejected. (No overwriting happens.) In Apalache, this will be just a constraint, the solver has to come up with a value of current that matches the constraint.

What we do here is a common idiom in verification: Non-deterministically guess a value and then constrain it with your assumptions. Essentially, all symbolic tools use this idiom, one way or another.

ancazamfir · 2020-06-11T10:20:45Z

docs/spec/lightclient/Lightclient_A_1.tla

+        /\ IF nextHeight \in DOMAIN fetchedLightBlocks
+           THEN /\ LightStoreGetInto(current, nextHeight)
+                /\ UNCHANGED fetchedLightBlocks
+           ELSE /\ FetchLightBlockInto(current, nextHeight)
+                /\ fetchedLightBlocks' = LightStoreUpdateBlocks(fetchedLightBlocks, current)


Would it be possible to make this into something like:

Suggested change

/\ IF nextHeight \in DOMAIN fetchedLightBlocks

THEN /\ LightStoreGetInto(current, nextHeight)

/\ UNCHANGED fetchedLightBlocks

ELSE /\ FetchLightBlockInto(current, nextHeight)

/\ fetchedLightBlocks' = LightStoreUpdateBlocks(fetchedLightBlocks, current)

/\ IF GetFromStore(current, store, nextHeight) THEN

newStore = store

ELSE

/\ FetchLightBlockInto(current, nextHeight)

/\ newStore = UpdateStore(store, current)

...so it's easier to follow with the spec and code.

This will be hard to do without introducing side effects. In your suggestion, current and store are updated simultaneously. In the proposed code, we would compute new store and constrain current. These are two different things that should not happen in the same place, for clarity of the spec.

It would be really cool to discuss this question and the above question in a dev session. This is really something, where the programming ends and logic starts :-)

ancazamfir · 2020-06-11T10:28:57Z

docs/spec/lightclient/Lightclient_A_1.tla

+                    THEN "working"
+                    ELSE "finishedSuccess"
+              /\ \E newHeight \in HEIGHTS:
+                 /\ ScheduleTo(newHeight, nextHeight, TARGET_HEIGHT, current)


This is nicer than english spec as we know where we are. So we could say: pick a height in (nextHeight, TARGET_HEIGHT]

Suggested change

/\ ScheduleTo(newHeight, nextHeight, TARGET_HEIGHT, current)

/\ ScheduleTo(newHeight, nextHeight, TARGET_HEIGHT)

Here you like a non-deterministic choice 👍

ancazamfir · 2020-06-11T10:32:25Z

docs/spec/lightclient/Lightclient_A_1.tla

+                *)
+              /\ lightBlockStatus' = LightStoreUpdateStates(lightBlockStatus, nextHeight, "StateUnverified")
+              /\ \E newHeight \in HEIGHTS:
+                 /\ ScheduleTo(newHeight, nextHeight, TARGET_HEIGHT, latestVerified)


..and here: pick a height in (latestVerified, nextHeight-1]

Suggested change

/\ ScheduleTo(newHeight, nextHeight, TARGET_HEIGHT, latestVerified)

/\ ScheduleTo(newHeight, latestVerified, nextHeight-1)

Josef and I still think that we should not change the number of parameters and the parameters to CanScheduleTo, as we may change the scheduling decision in the future.

konnov · 2020-06-26T10:15:15Z

@ancazamfir, thank you for the deep review! Josef and I went over your comments and implemented some of them (and commented on the ones we skipped).

josef-widder

Looks great. We will add tags later. This shouldn't block merging.

konnov added 10 commits June 2, 2020 11:17

the initial version from the old light client bisection

bd8765b

an intermediate version

6d837b0

the first version that Josef and I believe is ok

39166f7

something is working

862d2f4

a workaround for #148 in apalache

84d2f99

super fast encoding: the blockchain is initialized, time is integer

beca214

more realistic time resolution

82fa485

the complexity bound and other cool things

1a00111

comments on the light client spec

80894fa

cleaned up the MC models

c7ebb8f

konnov requested review from brapse, romac, milosevic, ebuchman, ancazamfir, istoilkovska, josef-widder and andrey-kuprianov June 9, 2020 15:00

konnov added 2 commits June 10, 2020 12:52

removed the now redundant height

8a367b8

fixed a bug in Next and simplified it

011d816

romac changed the title ~~Igor/lightclient tla~~ Light Client TLA+ Specification Jun 10, 2020

updating the experimental setup for the AFT paper

e732dd2

ancazamfir reviewed Jun 11, 2020

View reviewed changes

reordering the experiments

492ebb7

ebuchman mentioned this pull request Jun 21, 2020

Transfer specs from verification repo #356

Closed

josef-widder mentioned this pull request Jun 22, 2020

light-client/Blockchain.tla false properties pass informalsystems/verification#10

Open

romac added the light-client Issues/features which involve the light client label Jun 25, 2020

josef-widder mentioned this pull request Jun 26, 2020

Dev session to discuss TLA+ modeling #378

Closed

updates after review by Anca

2aee159

josef-widder approved these changes Jun 26, 2020

View reviewed changes

brapse merged commit bb86a3d into master Jun 26, 2020

brapse deleted the igor/lightclient-tla branch June 26, 2020 13:00

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Light Client TLA+ Specification #314

Light Client TLA+ Specification #314

konnov commented Jun 9, 2020

ancazamfir left a comment

ancazamfir Jun 11, 2020

konnov Jun 26, 2020

konnov Jun 26, 2020

ancazamfir Jun 11, 2020

konnov Jun 26, 2020

ancazamfir Jun 11, 2020

konnov Jun 26, 2020

konnov Jun 26, 2020

ancazamfir Jun 11, 2020

konnov Jun 26, 2020

ancazamfir Jun 11, 2020

konnov Jun 26, 2020

ancazamfir Jun 11, 2020

konnov Jun 26, 2020 •

edited

Loading

konnov Jun 26, 2020

konnov Jun 26, 2020

ancazamfir Jun 11, 2020

konnov Jun 26, 2020

ancazamfir Jun 11, 2020

konnov Jun 26, 2020

ancazamfir Jun 11, 2020

konnov Jun 26, 2020

ancazamfir Jun 11, 2020

konnov Jun 26, 2020

konnov commented Jun 26, 2020

josef-widder left a comment

	OneThird(trusted, untrusted) ==
	TrustedValidatorSet(trusted, untrusted) ==

		LightStoreGetInto(block, height) ==
		block = fetchedLightBlocks[height]

	ScheduleTo(newHeight, pNextHeight, pTargetHeight, pLatestVerified) ==
	CanScheduleTo(newHeight, pLatestVerified, pNextHeight, pTargetHeight) ==

	ScheduleTo(newHeight, pNextHeight, pTargetHeight, pLatestVerified) ==
	CanSchedule(newHeight, low, high) ==

	/\ ScheduleTo(newHeight, nextHeight, TARGET_HEIGHT, current)
	/\ ScheduleTo(newHeight, nextHeight, TARGET_HEIGHT)

	/\ ScheduleTo(newHeight, nextHeight, TARGET_HEIGHT, latestVerified)
	/\ ScheduleTo(newHeight, latestVerified, nextHeight-1)

Light Client TLA+ Specification #314

Light Client TLA+ Specification #314

Conversation

konnov commented Jun 9, 2020

ancazamfir left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

konnov Jun 26, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

konnov commented Jun 26, 2020

josef-widder left a comment

Choose a reason for hiding this comment

konnov Jun 26, 2020 •

edited

Loading