Skip to content
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

Slash packet throttling #462

Merged
merged 210 commits into from
Dec 16, 2022
Merged
Show file tree
Hide file tree
Changes from 207 commits
Commits
Show all changes
210 commits
Select commit Hold shift + click to select a range
d16ba5c
wip
shaspitz Oct 25, 2022
fda4bff
Update module.go
shaspitz Oct 25, 2022
0c969c2
wip
shaspitz Oct 26, 2022
b3d8d37
tests pass
shaspitz Oct 26, 2022
7bd74b9
Update relay.go
shaspitz Oct 27, 2022
aeaa892
Update relay.go
shaspitz Oct 27, 2022
94b1edf
Update relay.go
shaspitz Oct 27, 2022
abf9458
Update relay.go
shaspitz Oct 27, 2022
d88665b
wip
shaspitz Oct 27, 2022
a4e1e1b
still wip
shaspitz Oct 28, 2022
b0e8818
Merge branch 'main' into circuit-breaker
shaspitz Oct 28, 2022
320570a
panic with too many packets
shaspitz Oct 28, 2022
35540d6
Update relay.go
shaspitz Oct 28, 2022
176f31e
wip
shaspitz Oct 31, 2022
3872f37
checkpoint
shaspitz Nov 1, 2022
5e22474
Update throttle.go
shaspitz Nov 1, 2022
2773c48
make relay.go closer to main
shaspitz Nov 1, 2022
c00c270
Merge branch 'main' into circuit-breaker
shaspitz Nov 1, 2022
14be208
merge fixes
shaspitz Nov 1, 2022
a878f5a
Update expected_keepers.go
shaspitz Nov 1, 2022
1fa0608
Update throttle_test.go
shaspitz Nov 1, 2022
6e2ade5
Update throttle.go
shaspitz Nov 1, 2022
46c27be
second queue is now implemented
shaspitz Nov 3, 2022
fa09479
smalls
shaspitz Nov 3, 2022
018de7c
Update throttle.go
shaspitz Nov 3, 2022
0681221
removed pointer silliness
shaspitz Nov 3, 2022
5d1241a
Merge branch 'main' into circuit-breaker
shaspitz Nov 3, 2022
92f0368
Update throttle_test.go
shaspitz Nov 3, 2022
8242893
test improvements
shaspitz Nov 3, 2022
c0cac2f
small
shaspitz Nov 3, 2022
0a745fa
where it's called
shaspitz Nov 3, 2022
d5758a8
Update relay.go
shaspitz Nov 3, 2022
8ffe723
comments n stuff
shaspitz Nov 3, 2022
800d6af
Update throttle.go
shaspitz Nov 3, 2022
9b787dd
Update throttle.go
shaspitz Nov 3, 2022
909e23f
comments
shaspitz Nov 3, 2022
f894949
wip
shaspitz Nov 3, 2022
29351a8
callbacks
shaspitz Nov 3, 2022
a1ff563
cleans
shaspitz Nov 4, 2022
50259fc
mas tests
shaspitz Nov 4, 2022
b605f9f
Update README.md
shaspitz Nov 4, 2022
336e7cc
less diff
shaspitz Nov 4, 2022
f4b0c1e
Merge branch 'main' into circuit-breaker
shaspitz Nov 4, 2022
cb36e31
mas
shaspitz Nov 4, 2022
6c5b77b
Merge branch 'main' into circuit-breaker
shaspitz Nov 7, 2022
1dbe42c
keys
shaspitz Nov 7, 2022
9dfc06f
wip
shaspitz Nov 7, 2022
8a8f88c
changes
shaspitz Nov 7, 2022
54d231f
Update params.go
shaspitz Nov 7, 2022
a3b7555
size constraints
shaspitz Nov 8, 2022
fd55b51
Update keys_test.go
shaspitz Nov 8, 2022
c1c4b60
Update throttle_test.go
shaspitz Nov 8, 2022
c7db22e
Merge branch 'main' into circuit-breaker-params-rebase
shaspitz Nov 8, 2022
ef8124b
Merge branch 'main' into circuit-breaker
shaspitz Nov 8, 2022
d418dc2
Merge branch 'main' into circuit-breaker-params-rebase
shaspitz Nov 8, 2022
fe2bb3f
Merge branch 'main' into circuit-breaker-params-rebase
shaspitz Nov 8, 2022
6582a17
Merge branch 'main' into circuit-breaker
shaspitz Nov 8, 2022
fdf12ab
wip
shaspitz Nov 8, 2022
900de76
on recv new behavior and test
shaspitz Nov 8, 2022
495a654
on recv slash packet
shaspitz Nov 8, 2022
01098af
so close
shaspitz Nov 9, 2022
1a88a1a
clean
shaspitz Nov 9, 2022
5c061c3
Update slashing.go
shaspitz Nov 9, 2022
5d1dd8b
cleans
shaspitz Nov 9, 2022
c6d2652
wip
shaspitz Nov 9, 2022
0458040
Merge branch 'circuit-breaker-params-rebase' into circuit-breaker
shaspitz Nov 9, 2022
09a9361
params
shaspitz Nov 10, 2022
440655e
wip
shaspitz Nov 10, 2022
f955739
tests
shaspitz Nov 10, 2022
0475032
changes
shaspitz Nov 11, 2022
3af89d1
Merge branch 'main' into testutil-refactor
shaspitz Nov 11, 2022
8a55b0a
mas
shaspitz Nov 11, 2022
b83d8cb
Update README.md
shaspitz Nov 11, 2022
3c5c817
Update README.md
shaspitz Nov 12, 2022
9cfbc76
Update README.md
shaspitz Nov 12, 2022
69596b6
sorry for the friday night emails
shaspitz Nov 12, 2022
e7cde9e
Update instance_test.go
shaspitz Nov 12, 2022
71bf63b
wip
shaspitz Nov 12, 2022
0b924ac
wip
shaspitz Nov 15, 2022
226aa95
wip
shaspitz Nov 15, 2022
5f6952e
wip
shaspitz Nov 15, 2022
b64fece
wip
shaspitz Nov 15, 2022
bc577e0
wip
shaspitz Nov 15, 2022
48a8772
wip
shaspitz Nov 15, 2022
a4b755b
wip
shaspitz Nov 15, 2022
9f45d14
works
shaspitz Nov 15, 2022
b51510d
Update generic_setup.go
shaspitz Nov 15, 2022
8dca707
Merge branch 'main' into e2e-multiple-consumers
shaspitz Nov 15, 2022
7dcce36
Update setup.go
shaspitz Nov 15, 2022
ec469f1
smol
shaspitz Nov 15, 2022
dd8983d
small
shaspitz Nov 15, 2022
714be77
path to ccv chan setup
shaspitz Nov 15, 2022
49b45f2
todos
shaspitz Nov 15, 2022
df45b72
Update setup.go
shaspitz Nov 15, 2022
5db64cb
Merge branch 'main' into e2e-multiple-consumers
shaspitz Nov 16, 2022
d4c8df1
Create debug_test.go
shaspitz Nov 16, 2022
e89d605
democ
shaspitz Nov 17, 2022
bcc911b
Update debug_test.go
shaspitz Nov 17, 2022
8b85c90
Merge branch 'main' into debug-file
shaspitz Nov 17, 2022
02933c6
Merge branch 'debug-file' into e2e-multiple-consumers
shaspitz Nov 17, 2022
6d078c9
Merge branch 'main' into debug-file
shaspitz Nov 17, 2022
0c1e582
setup all ccv channels
shaspitz Nov 18, 2022
e771e00
Merge branch 'main' into debug-file
shaspitz Nov 18, 2022
3feffc3
bump to main
shaspitz Nov 18, 2022
5820981
another bump, missed one
shaspitz Nov 18, 2022
869a0fa
Merge branch 'main' into debug-file
jtremback Nov 18, 2022
fb6f948
Merge branch 'main' into debug-file
shaspitz Nov 18, 2022
d78b599
fix after merge main
shaspitz Nov 18, 2022
19669d4
Merge branch 'debug-file' into e2e-multiple-consumers
shaspitz Nov 18, 2022
91d5203
fixes
shaspitz Nov 18, 2022
631fbf9
Update slashing.go
shaspitz Nov 18, 2022
97eb82e
expired client tests
shaspitz Nov 18, 2022
741f387
Merge branch 'debug-file' into e2e-multiple-consumers
shaspitz Nov 18, 2022
3a384fd
checks
shaspitz Nov 18, 2022
04cee6a
fixed the stuff
shaspitz Nov 19, 2022
a55fd94
smol
shaspitz Nov 19, 2022
36b78fb
changes
shaspitz Nov 21, 2022
c476872
Merge branch 'mapped-sent-packets-fix' into e2e-multiple-consumers
shaspitz Nov 21, 2022
aba6ccc
updates
shaspitz Nov 21, 2022
1598b5b
cleans
shaspitz Nov 21, 2022
7d2e39a
clean
shaspitz Nov 21, 2022
71463e0
todo
shaspitz Nov 21, 2022
c1a9926
fixes
shaspitz Nov 21, 2022
9587b4c
cleans
shaspitz Nov 21, 2022
3b81eb2
Update slashing.go
shaspitz Nov 21, 2022
7c85833
Update slashing.go
shaspitz Nov 21, 2022
69a5472
Merge branch 'main' into circuit-breaker
shaspitz Nov 21, 2022
9fe10c9
mod tidy
shaspitz Nov 21, 2022
4f2c90d
fix build errs
shaspitz Nov 21, 2022
94ce770
Merge branch 'e2e-multiple-consumers' into circuit-breaker
shaspitz Nov 21, 2022
cef81a1
test fixes
shaspitz Nov 21, 2022
5be6f87
Update slashing.go
shaspitz Nov 21, 2022
9cb7c54
Update throttle.go
shaspitz Nov 21, 2022
8390547
base rounding
shaspitz Nov 22, 2022
f5a08c4
mas unit tests
shaspitz Nov 22, 2022
5fdfef7
updates
shaspitz Nov 22, 2022
9da9224
comments
shaspitz Nov 22, 2022
67e1ead
comments
shaspitz Nov 22, 2022
eea4620
cleans
shaspitz Nov 23, 2022
ef4c4e9
clean
shaspitz Nov 23, 2022
59e0b65
small
shaspitz Nov 23, 2022
91c2cc3
sin gas
shaspitz Nov 24, 2022
1f3829f
more understandable logic
shaspitz Nov 24, 2022
3ed56cb
Merge branch 'main' into circuit-breaker
shaspitz Nov 24, 2022
b663ece
crypto rand
shaspitz Nov 24, 2022
d034e61
utils
shaspitz Nov 24, 2022
82643d8
one e2e
shaspitz Nov 24, 2022
358d90e
helpers
shaspitz Nov 25, 2022
f3ebbf4
Update slashing.go
shaspitz Nov 25, 2022
9290ed2
helpers
shaspitz Nov 25, 2022
000c83d
cleans
shaspitz Nov 25, 2022
ab03715
shiz works
shaspitz Nov 25, 2022
a5d22c9
tcs
shaspitz Nov 25, 2022
a09dd87
smalls
shaspitz Nov 25, 2022
0391a0e
un mas
shaspitz Nov 26, 2022
5f14fb3
allowance changing test
shaspitz Nov 26, 2022
34bfb33
smol
shaspitz Nov 26, 2022
6ee0872
smol
shaspitz Nov 26, 2022
af5ed0d
e2e tests are done
shaspitz Nov 26, 2022
7ddd77e
lets try this
shaspitz Nov 26, 2022
aa92173
Merge branch 'main' into circuit-breaker
jtremback Nov 28, 2022
55df41c
Key Assignment -> goc-december (#527)
jtremback Nov 28, 2022
20ef4c3
Merge branch 'goc-december' into circuit-breaker
jtremback Nov 28, 2022
44e86ab
Fix errors in merge commit, comment out failing TestRelayAndApplySlas…
jtremback Nov 28, 2022
1a8a08e
add simon's test fixes
shaspitz Nov 29, 2022
c1d909d
Update state.go
shaspitz Nov 29, 2022
e35dbe7
last replenish time -> last full time
shaspitz Nov 29, 2022
ba9965e
readme
shaspitz Nov 29, 2022
624937e
increment i
shaspitz Nov 29, 2022
5cdbfcd
shared method
shaspitz Nov 29, 2022
9904325
iteration change
shaspitz Nov 29, 2022
c238f4b
Meter allowance lockstep (#553)
shaspitz Dec 3, 2022
5b8d2c7
log
shaspitz Dec 5, 2022
b28e176
requested key format changes (#560)
shaspitz Dec 6, 2022
35192c0
Throttle garbage collection (#557)
shaspitz Dec 7, 2022
1247cae
update invariant
shaspitz Dec 8, 2022
a759c07
Throttle bug fixes + req refactors (#565)
shaspitz Dec 8, 2022
01b13d3
weird
shaspitz Dec 9, 2022
f4ab7d9
Merge branch 'main' into circuit-breaker
shaspitz Dec 10, 2022
1ebc8ca
merge fixes to build
shaspitz Dec 10, 2022
ce64f39
tests now pass
shaspitz Dec 10, 2022
5ce8ea2
name change
shaspitz Dec 10, 2022
28867c9
better ordering tests
shaspitz Dec 10, 2022
9a00a9b
remove integration test diff
shaspitz Dec 12, 2022
1f920b4
avoid double call to address mapping
shaspitz Dec 12, 2022
1dda237
Update throttle.go
shaspitz Dec 12, 2022
f744762
0 included in iteration start
shaspitz Dec 12, 2022
37dd296
naming refactors
shaspitz Dec 12, 2022
a8ea5df
Update keys_test.go
shaspitz Dec 12, 2022
589e019
more refactors
shaspitz Dec 13, 2022
1010775
clarify allowance terminology
shaspitz Dec 13, 2022
dcdf3d2
update doc with explanation on min value
shaspitz Dec 13, 2022
5487719
md clarification
shaspitz Dec 13, 2022
81363e4
Update throttle.md
shaspitz Dec 13, 2022
408ff0c
swap replenish order
shaspitz Dec 13, 2022
9d1b6bf
add max limit note
shaspitz Dec 13, 2022
fcf29bc
#533 Adds normal operation diff testing
danwt Dec 13, 2022
072a18c
Merge branch 'main' into circuit-breaker
shaspitz Dec 13, 2022
e9f40b0
Merge branch 'main' into circuit-breaker
shaspitz Dec 14, 2022
bcc6566
progress save
shaspitz Dec 14, 2022
5f2d8ae
cleans
shaspitz Dec 14, 2022
cd3887c
name change
shaspitz Dec 15, 2022
bd2e4d0
Bugfix (#605)
shaspitz Dec 15, 2022
2e246d1
Circuit breaker refactor (#606)
shaspitz Dec 16, 2022
892c66b
quick fix
shaspitz Dec 16, 2022
2e03991
small key correction
shaspitz Dec 16, 2022
0b595ea
smol
shaspitz Dec 16, 2022
80a9cfa
Merge branch 'main' into circuit-breaker
shaspitz Dec 16, 2022
3b03354
don't store time length
shaspitz Dec 16, 2022
ab11cee
use big endian, shawn you dingus
shaspitz Dec 16, 2022
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
106 changes: 106 additions & 0 deletions docs/throttle.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,106 @@
# Slash/VSCMatured Packet Throttling

## Background

The CCV spec is based around the assumption that the provider binary and all consumers binaries are non-malicious, and follow the defined protocols. In practice, this assumption may not hold. A malicious binary could potentially sneak code into a consumer chain which is able to send many downtime or double signing packets at once to the provider.

Without packet throttling, an attacker could then create validators just below the provider's active set, and slash every honest validator at once. These honest validators are then jailed, and control of the chain passes over to the attacker's validators. This enables the attacker to commit arbitrary state on the provider, and to potentially steal all tokens bridged to the provider over IBC.

A solution to this issue is to handle slash packets on the provider such that validators would have more time to notice such an attack scenario is happening. With more time, validators can more effectively respond to the situation compared to everyone getting slashed instantaneously. The implementation in this repo of such a solution is to throttle slash and VSCMatured packets as described below.

## System Properties - CCV

The system properties maintained for CCV are defined here: [CCV spec - Consumer Initiated Slashing](https://github.com/cosmos/ibc/blob/main/spec/app/ics-028-cross-chain-validation/system_model_and_properties.md#consumer-initiated-slashing).

TODO: Update `Provider Slashing Warranty` to accommodate that slash requests are not always applied on the same block that the provider receives a slash packet.

## Practical/Implementation Properties

One property of this implementation (that probably doesn't need to be in the spec) is that if any of the chain-specific packet data queues become larger than `MaxPendingSlashingPackets (param)`, then the provider binary will panic, and the provider chain will halt. Therefore this param should be set carefully. See [PanicIfTooMuchThrottledPacketData](../x/ccv/provider/keeper/throttle.go#L264) for more details. This behavior is included so that if the provider binaries are queuing up more packet data than machines can handle, the provider chain halts deterministically between validators.

## Data structure - Global entry queue

There exists a single queue which stores "pending slash packet entries". These entries allow the provider to appropriately handle slash packets sent from any consumer in FIFO ordering. This queue is responsible for coordinating the order that slash packets (from multiple chains) are handled over time.

## Data structure - Per-chain data queue

For each established consumer, there exists a queue which stores "pending packet data". Ie. pending slash packet data is queued together with pending VSC matured packet data in FIFO ordering. Order is enforced by IBC sequence number. These "per-chain" queues are responsible for coordinating the order that slash packets are handled in relation to VSC matured packets from the same chain.

## Reasoning - Multiple queues

For reasoning on why this feature was implemented with multiple queues, see [spec](https://github.com/cosmos/ibc/blob/main/spec/app/ics-028-cross-chain-validation/system_model_and_properties.md#consumer-initiated-slashing). Specifically the section on _VSC Maturity and Slashing Order_. There are other ways to ensure such a property (like a queue of linked lists, etc.), but the implemented algorithm seemed to be the most understandable and easiest to implement with a KV store.

## IBC hook - OnRecvSlashPacket

Upon the provider receiving a slash packet from any of the established consumers, two things occur:

1. A pending slash packet entry is queued.
2. The data of such a packet is added to the per-chain queue

## IBC hook - OnRecvVSCMaturedPacket

Upon the provider receiving a VSCMatured packet from any of the established consumers, the following occurs:

1. If the per-chain queue for the consumer that sent this packet is empty, handle the VSC matured packet immediately.
2. Else, add the VSCMatured packet data to the per-chain queue, behind one or more existing packet data instances (which could include slash packet data and/or other VSCMatured packet data)

## Persisted State - Slash Meter

There exists one slash meter on the provider which stores an amount of voting power (integer), corresponding to an allowance of validators that can be jailed/tombstoned over time. This meter is initialized to a certain value on genesis, decremented whenever a slash packet is handled, and periodically replenished as decided by on-chain params.

## Endblocker handling - HandlePendingSlashPackets

Every endblocker the following psuedocode is executed

```typescript
meter := getSlashMeter()

// Keep iterating as long as the meter has positive gas and slash packet entries exist
while meter.IsPositive() && entriesExist() {
// Get next entry in queue
entry := getNextSlashPacketEntry()
// Decrement slash meter by the voting power that will be removed from the valset from handling this slash packet
valPower := entry.getValPower()
meter = meter - valPower
// Using the per-chain queue, handle the single slash packet using its queued data,
// then handle all trailing VSCMatured packets for this consumer
handleSlashPacketAndTrailingVSCMaturedPackets(entry)
// Delete entry in global queue, delete handled data
entry.Delete()
deletePendingSlashPacketData()
deleteTrailingVSCMaturedPacketData()
}
```

## Endblocker handling - Slash Meter Replenishment

Once the slash meter becomes not full, it'll be replenished after `SlashMeterReplenishPeriod (param)` by incrementing the meter with its allowance for the replenishment block, where `allowance` = `SlashMeterReplenishFraction (param)` * `currentTotalVotingPower`. The slash meter will never exceed its current allowance (fn of the total voting power for the block) in value. Note a few things:

1. The slash meter can go negative in value, and will do so when handling a single slash packet that jails a validator with significant voting power. In such a scenario, the slash meter may take multiple replenishment periods to once again reach a positive value, meaning no other slash packets may be handled for multiple replenishment periods.
2. Total voting power of a chain changes over time, especially as validators are jailed/tombstoned. As validators are jailed, total voting power decreases, and so does the slashing allowance for specific blocks.
3. The voting power allowance added to the slash meter during replenishment will always be greater than or equal to 1. If the `SlashMeterReplenishFraction (param)` is set too low, integer rounding will put this minimum value into effect. That is, if `SlashMeterReplenishFraction` * `currentTotalVotingPower` < 1, then the effective allowance would be 1. This min value of allowance ensures that there's some packets handled over time, even if that is a very long time. It's a crude solution to an edge case caused by too small of a replenishment fraction.

The behavior described above is achieved by executing `CheckForSlashMeterReplenishment()` every endblock.

## Throttling Invariant

Using on-chain params and the sub protocol defined, slash packet throttling is implemented such that the following invariant is maintained (in addition to those already defined in the CCV spec).

For the following invariant to hold, these points must be true:

- We assume the total voting power of the chain (as a function of delegations) does not significantly increase over the course of the attack.
- The final slashed validator does not have more than `SlashMeterReplenishFraction` of total voting power on the provider.
- `SlashMeterReplenishFraction` is large enough that `SlashMeterReplenishFraction` * `currentTotalVotingPower` > 1. Ie. the replenish fraction is set high enough that we can ignore rounding errors.
- `SlashMeterReplenishPeriod` is sufficiently longer than the time it takes to produce a block.

Invariant:

> If we define a consumer initiated slash attack to start when the first slash packet from such an attack is received by the provider, and we define the initial validator set as the set that existed when the attack started, the time it takes to jail/tombstone `X`% of the initial validator set will be greater than or equal to `(X * SlashMeterReplenishPeriod / SlashMeterReplenishFraction) - 2 * SlashMeterReplenishPeriod`

Intuition: If jailings begin when the slash meter is full, then `SlashMeterReplenishFraction` of the provider validator set can be jailed immediately. The remaining jailings are only applied when the slash meter is positive in value, so the time it takes to jail the remaining `X - SlashMeterReplenishFraction` of the provider validator set is `(X - SlashMeterReplenishFraction) * SlashMeterReplenishPeriod / SlashMeterReplenishFraction`. However, the final validator could be jailed during the final replenishment period, with the meter being very small in value (causing it to go negative after jailing). So we subtract another `SlashMeterReplenishPeriod` term in the invariant to account for this.

Note this invariant could be adjusted with different slash meter protocols, but the current scheme is the simplest to implement and understand.

This invariant is useful because it allows us to reason about the time it takes to jail a certain percentage of the initial provider validator set from consumer initiated slash requests. For example, if `SlashMeterReplenishFraction` is set to 0.06, then it takes no less than 4 replenishment periods to jail 33% of the initial provider validator set on the Cosmos Hub. Note that as of writing this on 11/29/22, the Cosmos Hub does not have a validator with more than 6% of total voting power.

Note also that 4 replenishment period is a worst case scenario that depends on well crafted attack timings.
21 changes: 17 additions & 4 deletions tests/difference/core/driver/core_test.go
Original file line number Diff line number Diff line change
Expand Up @@ -240,7 +240,9 @@ func (s *CoreSuite) matchState() {
// TODO: delegations
s.Require().Equalf(int64(s.traces.DelegatorTokens()), s.delegatorBalance(), diagnostic+"P del balance mismatch")
for j := 0; j < initState.NumValidators; j++ {
s.Require().Equalf(s.traces.Jailed(j) != nil, s.isJailed(int64(j)), diagnostic+"P jail status mismatch for val %d", j)
a := s.traces.Jailed(j) != nil
b := s.isJailed(int64(j))
s.Require().Equalf(a, b, diagnostic+"P jail status mismatch for val %d", j)
}
}
if chain == C {
Expand All @@ -259,6 +261,7 @@ func (s *CoreSuite) matchState() {
}

func (s *CoreSuite) executeTrace() {

for i := range s.traces.Actions() {
s.traces.CurrentActionIx = i

Expand Down Expand Up @@ -310,6 +313,8 @@ func (s *CoreSuite) TestAssumptions() {
s.T().Fatal(FAIL_MSG)
}

// TODO: write assumption that checks that throttle params are appropriate

// Delegator balance is correct
s.Require().Equal(int64(initState.InitialDelegatorTokens), s.delegatorBalance())

Expand Down Expand Up @@ -428,9 +433,10 @@ func (s *CoreSuite) TestTraces() {
s.traces = Traces{
Data: LoadTraces("traces.json"),
}
// s.traces.Data = []TraceData{s.traces.Data[69]}
shortest := -1
shortestLen := 10000000000
for i := range s.traces.Data {
s.Run(fmt.Sprintf("Trace num: %d", i), func() {
if !s.Run(fmt.Sprintf("Trace num: %d", i), func() {
// Setup a new pair of chains for each trace
s.SetupTest()

Expand All @@ -448,8 +454,15 @@ func (s *CoreSuite) TestTraces() {
// Record information about the trace, for debugging
// diagnostics.
s.executeTrace()
})
}) {
if s.traces.CurrentActionIx < shortestLen {
shortest = s.traces.CurrentTraceIx
shortestLen = s.traces.CurrentActionIx
}
}
}
fmt.Println("Shortest [traceIx, actionIx]:", shortest, shortestLen)

}

func TestCoreSuite(t *testing.T) {
Expand Down
7 changes: 7 additions & 0 deletions tests/difference/core/driver/setup.go
Original file line number Diff line number Diff line change
Expand Up @@ -678,6 +678,13 @@ func (b *Builder) build() {

b.setSlashParams()

// TODO: tidy up before merging into main
prams := b.providerKeeper().GetParams(b.ctx(P))
prams.SlashMeterReplenishFraction = "1.0"
prams.SlashMeterReplenishPeriod = time.Second * 1
b.providerKeeper().SetParams(b.ctx(P), prams)
b.providerKeeper().InitializeSlashMeter(b.ctx(P))

// Set light client params to match model
tmConfig := ibctesting.NewTendermintConfig()
tmConfig.UnbondingPeriod = b.initState.UnbondingP
Expand Down
2 changes: 1 addition & 1 deletion tests/difference/core/driver/traces.json

Large diffs are not rendered by default.

1 change: 1 addition & 0 deletions tests/difference/core/model/src/common.ts
Original file line number Diff line number Diff line change
Expand Up @@ -181,6 +181,7 @@ type ModelInitState = {
downtimeSlashAcks: number[];
tombstoned: boolean[];
matureUnbondingOps: number[];
queue: (Slash | VscMatured)[];
};
};

Expand Down
1 change: 1 addition & 0 deletions tests/difference/core/model/src/constants.ts
Original file line number Diff line number Diff line change
Expand Up @@ -56,6 +56,7 @@ const MODEL_INIT_STATE: ModelInitState = {
downtimeSlashAcks: [],
tombstoned: [false, false, false, false],
matureUnbondingOps: [],
queue: [],
},
staking: {
delegation: [4000, 3000, 2000, 1000],
Expand Down
29 changes: 25 additions & 4 deletions tests/difference/core/model/src/model.ts
Original file line number Diff line number Diff line change
Expand Up @@ -374,6 +374,8 @@ class CCVProvider {
tombstoned: boolean[];
// unbonding operations to be completed in EndBlock
matureUnbondingOps: number[];
// queue
queue: (Slash | VscMatured)[];

constructor(model: Model, { ccvP }: ModelInitState) {
this.m = model;
Expand All @@ -382,6 +384,7 @@ class CCVProvider {

endBlockCIS = () => {
this.vscIDtoH[this.vscID] = this.m.h[P] + 1;
this.processPackets();
};

endBlockVSU = () => {
Expand Down Expand Up @@ -420,14 +423,32 @@ class CCVProvider {
};

onReceive = (data: PacketData) => {
// It's sufficient to use isDowntime field as differentiator
if ('isDowntime' in data) {
this.onReceiveSlash(data);
/*
TODO: tidy up before merging to main
This is some quick prototyping to get the tests passing
We have 1 consumer chain so the slash queue is the global queue
if the queue is empty we can just process the packet.
*/
if (this.queue.length == 0 && !('isDowntime' in data)) {
// Skip the queue
this.onReceiveVSCMatured(data as VscMatured);
} else {
this.onReceiveVSCMatured(data);
this.queue.push(data);
}
};

processPackets = () => {
this.queue.forEach((data) => {
// It's sufficient to use isDowntime field as differentiator
if ('isDowntime' in data) {
this.onReceiveSlash(data);
} else {
this.onReceiveVSCMatured(data);
}
});
this.queue = [];
};

onReceiveVSCMatured = (data: VscMatured) => {
if (this.vscIDtoOpIDs.has(data.vscID)) {
this.vscIDtoOpIDs.get(data.vscID)!.forEach((opID: number) => {
Expand Down
Loading