It turns out that encoding json.RawMessage is slow because
package json basically parses the message again to ensure it is valid.
We can avoid the slowdown by encoding the entire RPC notification once,
which yields a 30% speedup.
* rpc: make subscription test faster
reduces time for TestClientSubscriptionChannelClose
from 25 sec to < 1 sec.
* trie: cache trie nodes for faster sanity check
This reduces the time spent on TestIncompleteSyncHash
from ~25s to ~16s.
* core/forkid: speed up validation test
This takes the validation test from > 5s to sub 1 sec
* core/state: improve snapshot test run
brings the time for TestSnapshotRandom from 13s down to 6s
* accounts/keystore: improve keyfile test
This removes some unnecessary waits and reduces the
runtime of TestUpdatedKeyfileContents from 5 to 3 seconds
* trie: remove resolver
* trie: only check ~5% of all trie nodes
The String() version of BlockNumberOrHash uses decimal for all block numbers, including negative ones used to indicate labels. Switch to using BlockNumber.String() which encodes it correctly for use in the JSON-RPC API.
* Stop execution pool in rpc handler
All execution pools need to be closed properly. This fixes a potential goroutine leak caused by metric goutine created by each execution pool.
* Cancel only once
* added new api to support conditional transactions (EIP-4337) (#700)
* Refactored the code and updated the miner to check for the validity of options (#793)
* refactored the code and updated the miner to check for the validity of options
* added new errors -32003 and -32005
* added unit tests
* addressed comments
* Aa 4337 update generics (#799)
* poc
* minor bug fix
* use common.Hash
* updated UnmarshalJSON function (reference - tynes)
* fix
* done
* linters
* with test
* undo some unintentional changes
---------
Co-authored-by: Pratik Patil <pratikspatil024@gmail.com>
* handelling the block range and timestamp range, also made timestamp a pointer
---------
Co-authored-by: Evgeny Danilenko <6655321@bk.ru>
* Added filtering of conditional transactions in txpool (#920)
* added filtering of conditional transactions in txpool
* minor fix in ValidateKnownAccounts
* bug fix
* Supporting nil knownAccounts
* lints
* bundled transactions are not announced/broadcasted to the peers
* fixed after upstream merge
* few fixes
* sentry reject conditional transaction
* Changed the namespace of conditional transaction API from `eth` to `bor` (#985)
* added conditional transaction to bor namespace
* test comit
* test comit
* added conditional transaction
* namespapce changed to bor
* cleanup
* cleanup
* addressed comments
* reverted changes in ValidateKnownAccounts
* addressed comments and removed unwanted code
* addressed comments
* bug fix
* lint
* removed licence from core/types/transaction_conditional_test.go
---------
Co-authored-by: Evgeny Danilenko <6655321@bk.ru>
* Milestone Implementation
* Merge branch 'POS-347' into reciept-e2e-test
* Changes for testing, will be removed after testing
* Debugged the error
* Just for testing purpose
* refactor debug api methods, rename whitelist -> checkpoint
* remove first iteration based vars
* fix linters
* Rewind Changes
* Error changes
* RewindBack function in bor_checkpoint_verifier
* Testcases
* Added the fetch test for milestone and checkpoint
* Debugged the lint changes
* Debugged the lint changes
* Debugged the lint changes
* Debugged the lint changes
* Improved the error in Miner test file
* Improved the error of pointing to the wrong function
* Locking the sprint after the vote has been made on it.
* Adding more logs for testing
* Adding more logs for testing
* Adding more logs for testing
* Implemented the NoAckMilestone fetching mechanism
* Testcases for milestone implementation
* Testing code for fetchNoAckMilestone and fetchLastNoAckMilestone
* Testing changes
* refactor else-if
* Corrected the number of params in bor_ext.go
* Dummy API for testing
* Defined the GetVoteOnRootHash in interface
* Defined the GetVoteOnRootHash in interface
* Made changes in the web3ext file
* Added the GetVoteOnRootHash in PublicBlockChain API
* Added the GetVoteOnRootHash in filterBackend
* Added the log of Root and RooHash
* Removed the 0x from rootHash
* Just for testing purpose
* "GetVoteOnRootHash" mock implementation
* bor_test.go
* Added the test for milestone implementation
* Added service for fetching milestone by ID
* Improved the comments
* Removed the duplicate code
* use setter for borVerifier
* use setter for borVerifier
* refactor handleNoAckMilestone
* remove code repetition with retry function
* Converged the repetitive code
* after CR
* persistence
* persistence implementation
* feature flag
* Persistence Changes
* cr
* initial
* fix
* fix
* Whitelist Flag
* 1 Add:Included the milestone flag 2.Add:Hardlimit the rewind to maximum of 255 blocks
* Chg:Updated go.mod file
* Remove:Dubai Hardfork code
* Add:checked errors for call functions to the Db, Rmv: Remote Header variable from the IsValidPeer() function
* Fix:Linting issues'
* Add:MilestoneGRPC functions
* Fix:Lint issues
* Fix:Lint issues
* Fix: TestFetchMilestoneFromMockHeimdall
* Fix:Integrations tests
* Add:Test for sprint length and milestone changes
* Add:Functionality to fetch the finalized block
* Chg:Changed default val of TriesInmemory to 1024
* fix:Some functions of heimdallGRPC client
* Restored the GRPC functionality, was commented out for developing purpose
* Fix:Bor_checkpoint_Verfier function
* Test:Added the chain Rewinding test
* Test:Added the Sprint Length + Milestone merge test
* Add:Implemented the future milestone
* Add:Future milestone changes
* Add:Future milestone changes
* Chg: Voting on endBlockHash rather than rootHash
* Chg: Changed the logic of future milestone from rootHash checking to endBlockHash checking
* Fix:Using endBockHash while verifying the incoming milestone
* Chg:Variable names for better readiblity
* Fix:Testing changes
* Add:metrics for milestone implementation
* Add:Metrics for milestone implementatian
* Fix:Order of statements in a function for better optimization
* Chg:Removed unrequired file
* Fix:new variable intialization
* Add:Comment to increase readiblity
* Fix:Logs
* Chg:Name of GetVoteOnRootHash to GetVoteOnHash
* Fix:Linting issues
* Fixed linting issues
* Rmv: Unnecessary logs and Add:Skip test for long tests
* Fix:Checking current chain with whitelisted milestone or checkpoint in Finalized block function
* Fix:Test
* Fix:Whitelisting of Milestone and Checkpoint process
* Fix: Milestone JSON structure
* Chg:Testcases changes
* Fix:Change from VoteOnRootHash to VoteOnHash
* Fix:Variable name fix
* Fix:Finalized API
* internal/jsre/deps: update web3.js bundle
* Fix:milestone verifier
* Chg:Handling the long future chain import issue
* Fix:Lint issues
* Fix:TestLowDiffLongChain and TestPrunedImportSide tests, used hardcoded value 128 instead of DefaultTriesInMemory value
* Chg:Testcode for producing metrics
* Chg:Milestong polling value to 32 secs
* Add:Testcases
* Add:Implemented the check to fetch the milestoneId from heimdall before locking the fork
* Added GRPC method for FetchMilestoneID
* Fix:lint issue
* Fix:lint issue
* Skiped out the tests which were mainly used to produce the supporting data
* remove vcs build when running snyk
* Add:Improved the logs and comments
* fix linters
* Skipped some test as they are panic due to timeout issue in github
* Chg:Variable name LockerSprintNumber to LockedMilestoneNumber for better readablity and clarity
* Chg:Conflicting variable names in milestone test file
* Chg:Conflicting function names in milestone test file
* fix : minor fix in TestInsertingSpanSizeBlocks
* Fix:Mocking issue in TestInsertingSpanSizeBlocks
* Fix:GRPC Polyproto Version
* eth/downloader: skip peer drop due to whitelisting err
* eth, tests/bor: bug fixes and minor refactor
* Add:Implemented the milestone related functions in the HeimdallApp
* Fix:Lint Errors & Remove:Redundant Code
* Fix:Testing Errors
* Fix:Bor integeration tests
* Fix:Test errors
* update heimdall client mock files
* remove unused arguments
* remove redundant code
* Chg:Changed the milestone polling intervals
* Add: added block finality from whitelisted checkpoint
* skip future chain validation
* Add:confirmation check of 16 blocks over the end block while voting for the milestone in GetVoteHash() function
* Chg:Included endBlockNum in UnlockMutex function
* Add:Property based test for milestone
* Fix:Opening the lock while processing future milestone
* Add:Property based test for futureMilestone
* Defined the value of TempTriesInMemory
* Fixed the finalized api
* Fixed lint issues
* eth: add logs while fetching and rewinding
* fix linters: use default returns instead of recursive calls
* Fix:Milestone intergration test
* Add:GetVoteHash fn in mock backend
* tests/bor: fix mock span
* tests/bor: remove t.Parallel()
* use bor namespace in ethclient, fix mock function
---------
Co-authored-by: Vaibhav Jindal <vaibhavjindal29@gmail.com>
Co-authored-by: VaibhavJindal <74560896+VAIBHAVJINDAL3012@users.noreply.github.com>
Co-authored-by: Manav Darji <manavdarji.india@gmail.com>
Co-authored-by: Evgeny Danienko <6655321@bk.ru>
Co-authored-by: Shivam Sharma <shivam691999@gmail.com>
Co-authored-by: Anshal Shukla <shukla.anshal85@gmail.com>
We're trying a new named pipe library, which should hopefully fix some occasional failures in CI.
---------
Co-authored-by: Felix Lange <fjl@twurst.com>
This should fix#27726. With enough load, it might happen that the SetPongHandler
callback gets invoked before the call to SetReadDeadline is made in pingLoop. When
this occurs, the socket will end up with a 30s read deadline even though it got the pong,
which will lead to a timeout.
The fix here is processing the pong on pingLoop, synchronizing with the code that
sends the ping.
Package rpc uses cgo to find the maximum UNIX domain socket path
length. If exceeded, a warning is printed. This is the only use of cgo in this
package. It seems excessive to depend on cgo just for this warning, so
we now hard-code the usual limit for Linux instead.
---------
Co-authored-by: Felix Lange <fjl@twurst.com>
This adds two ways to check for subscription support. First, one can now check
whether the transport method (HTTP/WS/etc.) is capable of subscriptions using
the new Client.SupportsSubscriptions method.
Second, the error returned by Subscribe can now reliably be tested using this
pattern:
sub, err := client.Subscribe(...)
if errors.Is(err, rpc.ErrNotificationsUnsupported) {
// no subscription support
}
---------
Co-authored-by: Felix Lange <fjl@twurst.com>
This PR adds server-side limits for JSON-RPC batch requests. Before this change, batches
were limited only by processing time. The server would pick calls from the batch and
answer them until the response timeout occurred, then stop processing the remaining batch
items.
Here, we are adding two additional limits which can be configured:
- the 'item limit': batches can have at most N items
- the 'response size limit': batches can contain at most X response bytes
These limits are optional in package rpc. In Geth, we set a default limit of 1000 items
and 25MB response size.
When a batch goes over the limit, an error response is returned to the client. However,
doing this correctly isn't always possible. In JSON-RPC, only method calls with a valid
`id` can be responded to. Since batches may also contain non-call messages or
notifications, the best effort thing we can do to report an error with the batch itself is
reporting the limit violation as an error for the first method call in the batch. If a batch is
too large, but contains only notifications and responses, the error will be reported with
a null `id`.
The RPC client was also changed so it can deal with errors resulting from too large
batches. An older client connected to the server code in this PR could get stuck
until the request timeout occurred when the batch is too large. **Upgrading to a version
of the RPC client containing this change is strongly recommended to avoid timeout issues.**
For some weird reason, when writing the original client implementation, @fjl worked off of
the assumption that responses could be distributed across batches arbitrarily. So for a
batch request containing requests `[A B C]`, the server could respond with `[A B C]` but
also with `[A B] [C]` or even `[A] [B] [C]` and it wouldn't make a difference to the
client.
So in the implementation of BatchCallContext, the client waited for all requests in the
batch individually. If the server didn't respond to some of the requests in the batch, the
client would eventually just time out (if a context was used).
With the addition of batch limits into the server, we anticipate that people will hit this
kind of error way more often. To handle this properly, the client now waits for a single
response batch and expects it to contain all responses to the requests.
---------
Co-authored-by: Felix Lange <fjl@twurst.com>
Co-authored-by: Martin Holst Swende <martin@swende.se>