kaspanet / rusty-kaspa Goto Github PK
View Code? Open in Web Editor NEWKaspa full-node and related libraries in the Rust programming language. This is a stable version at the initial rollout phases.
License: ISC License
Kaspa full-node and related libraries in the Rust programming language. This is a stable version at the initial rollout phases.
License: ISC License
Is your feature request related to a problem? Please describe.
Yes - a user that only wants to use the node as an API does not need to receive tx messages. Not having to deal with txs will reduce mempool use.
Describe the solution you'd like
Implement the disable_relay_tx
flag. When enabled, this lets a node's peers that it doesn't want to receive transactions. The peers will not send txs to this node.
Describe alternatives you've considered
N/A
Additional context
One consideration is the issue of starvation: What if a node that wants to receive txs is only connected to peers that have DisableRelayTx=false
?
Notes
// TODO: disable_relay_tx from config/cmd
is where this would goBlockOnly
in config, and DisableRelayTx
in the rest of the codebase.https://docs.rs/serde_bytes/latest/serde_bytes/
The above crate promises faster serde Serialization / Deserialization on byte vectors and byte slices, as it claims standard serde is not optimized for variable length sequences already in byte format.
Some examples in our current codebase where this could be included are the fields script
inconsensus_core::tx::ScriptPublicKey
, paylod
in consensus_core::tx::Transaction
, signature_script
in consensus_core::tx::TransactionInput
.
Rusty kaspad (possibly other executables as well) logs to stderr instead of stdout, on Linux at least.
This adds complexity when processing output using command line tools.
Reproduce:
Can easily be reproduced with: ./kaspad | grep kaspad <- all output will be shown instead of only the lines containing kaspad
However, kaspad -h actually outputs to stdout: ./kaspad --help | grep kaspad <- only one line is output.
Fix:
Correct logging facility to always do console output to stdout.
See #131
And #131 (comment)
Describe the bug
Syncing during a pruning point shift may result in the node not accepting blocks, idling in an endless progression of ibd header sync.
To Reproduce
Steps to reproduce the behavior:
sync a node and make sure it is in the ibd header syncing stage when a pruning point shift occurs.
Expected behavior
A node that accepts blocks from peers
Desktop (please complete the following information):
OS:
PRETTY_NAME="Ubuntu 22.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.2 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
Kaspad:
v. 0.1.0
commit 7f26aa6cac1086e8ac5dc4ed9e1d0f12710d4c89 (HEAD -> prune, origin/prune)
Author: Michael Sutton <[email protected]>
Date: Mon May 29 18:17:08 2023 +0000
add lock yield logic to semaphore and rwlock
Additional context
Logs:
2023-05-30 15:11:44.192Z [INFO ] kaspad v0.1.0 is when i restarted
...
2023-05-30 15:12:03.723Z [INFO ] Validating level 225 from the pruning point proof
...
2023-05-30 15:12:34.984Z [INFO ] Validating level 0 from the pruning point proof
2023-05-30 15:12:44.285Z [INFO ] Setting d706324b72daf8aa92f008f22d5a336a58fa333ff6572f99b820e84821d8d971 as the current pruning point
2023-05-30 15:12:44.285Z [INFO ] Building the proof which was just applied (sanity test)
2023-05-30 15:12:44.653Z [INFO ] Proof was locally built successfully
2023-05-30 15:12:44.898Z [INFO ] Starting to process 2644 trusted blocks
2023-05-30 15:12:45.898Z [INFO ] Processed 2471 trusted blocks in the last 1.00s (total 2471)
2023-05-30 15:12:45.937Z [INFO ] Done processing trusted blocks
2023-05-30 15:12:54.475Z [INFO ] Processed 3 blocks and 4184 headers in the last 10.00s (6 transactions; 7387 parent references; 0 UTXO-validated blocks; 2.00 avg txs per block; 34046 avg block mass)
2023-05-30 15:12:58.605Z [INFO ] IBD: Processed 3071 block headers (1%)
...
2023-05-30 15:32:48.207Z [INFO ] IBD: Processed 271508 block headers (100%)
2023-05-30 15:32:48.517Z [INFO ] Processed 0 blocks and 1697 headers in the last 10.00s (0 transactions; 2886 parent references; 0 UTXO-validated blocks; 0.00 avg txs per block; 0 avg block mass)
2023-05-30 15:32:49.355Z [INFO ] Received 99 UTXO set chunks so far, totaling in 99000 UTXOs
...
2023-05-30 15:34:19.916Z [INFO ] Finished receiving the UTXO set. Total UTXOs: 8117830
2023-05-30 15:34:19.917Z [INFO ] Importing the UTXO set of the pruning point d706324b72daf8aa92f008f22d5a336a58fa333ff6572f99b820e84821d8d971
2023-05-30 15:34:58.818Z [INFO ] Resyncing the utxoindex...
2023-05-30 15:35:36.515Z [INFO ] Registering p2p flows for peer 49.0.240.99:45994 for protocol version 5
2023-05-30 15:35:36.515Z [INFO ] P2P Connected to incoming peer 49.0.240.99:45994
2023-05-30 15:36:01.118Z [INFO ] P2P, Router receive loop - incoming stream ended from peer 38.242.139.17:16111
2023-05-30 15:36:04.434Z [INFO ] IBD with peer 38.242.139.17:16111 completed with error: ConnectionClosed
2023-05-30 15:36:04.813Z [INFO ] IBD started with peer 51.91.82.136:50408
2023-05-30 15:36:08.575Z [INFO ] Processed 0 blocks and 424 headers in the last 10.00s (0 transactions; 762 parent references; 0 UTXO-validated blocks; 0.00 avg txs per block; 0 avg block mass)
2023-05-30 15:36:12.375Z [INFO ] IBD: Processed 1025 block headers (74%)
2023-05-30 15:36:15.451Z [INFO ] IBD: Processed 1387 block headers (100%)
...
2023-05-30 15:38:41.209Z [INFO ] IBD: Processed 6 block headers (100%)
2023-05-30 15:38:43.077Z [INFO ] P2P, Router receive loop - incoming stream ended from peer 77.37.202.136:16111
2023-05-30 15:38:43.078Z [INFO ] IBD with peer 77.37.202.136:16111 completed with error: ConnectionClosed
2023-05-30 15:38:43.230Z [INFO ] IBD started with peer 193.198.102.245:16111
2023-05-30 15:38:43.382Z [INFO ] IBD: Processed 1 block headers (100%)
2023-05-30 15:38:45.153Z [INFO ] P2P, Router receive loop - incoming stream ended from peer 193.198.102.245:16111
2023-05-30 15:38:45.154Z [INFO ] IBD with peer 193.198.102.245:16111 completed with error: ConnectionClosed
2023-05-30 15:38:45.349Z [INFO ] IBD started with peer 54.39.129.199:40084
2023-05-30 15:38:45.713Z [INFO ] IBD: Processed 3 block headers (100%)
Note: Buggy Behavior is consistent when restarting the node without the --reset-db
flag
Mutagen(https://github.com/llogiq/mutagen) is a cool tool that modify constants and control flows and checks if the tests actually fail under the modification, this allows to check how good are the tests, even if you have "full coverage" you might not actually test a lot of conditions and mutagen helps you find those
Would be much useful for exchanges & data analysis etc.
The current gRPC server in the Golang implementation operates in FIFO mode (It is my understanding that different types of responses can return out of order, but for the sake of this proposal, let's refer to this as FIFO). This processing mode currently trickles down into rusty-kaspa gRPC implementation.
Wallet instances operating on behalf of different users make multiple requests via RPC, however, if interfacing with a system that operates in a FIFO mode, requests have to be queued, which interferes with parallelism. The solution to this is to establish a dedicated connection for each user "context", however, this results in additional resource consumption in the form of open sockets. In the current JS WebSocket/gRPC proxy implementation, each WebSocket connection results in a dedicated gRPC connection, yielding 2x open sockets.
It would be desirable to modify Kaspa gRPC protocol messages to support an id
field supplied by the user during the request, carried throughout the RPC call execution, and returned with the response.
Having a dedicated id
property for each request would allow a single gRPC connection to post requests on behalf of different clients and match responses with the corresponding requests. This would in turn allow a proxy server to establish a single dedicated connection to rusty-kaspa reducing the number of open sockets and also reducing the CPU load required to handle large amounts of sockets.
Adding this would also significantly simplify the gRPC Matcher that was put together by @tiram88 which would, instead of checking the request queue head and then doing a linear search through pending gRPC requests would be able to maintain a simple HashMap of requests, resolving them by id.
NOTE: This should apply strictly to gRPC .proto
messages, not internal RPC message structures (they should be agnostic to RPC channels).
For backward compatibility with the Golang client, it would be ideal if the Golang implementation also supports id propagation. This would allow the Rust gRPC client to interop with Golang via a single socket channel.
The FIFO mechanism currently used, imposes what sums up to be the processing queue for each client. This, at expense of multiple sockets, creates a per-client "pacing" mechanism. Removal of this queue requirement by introducing id
-based processing can result in heavier processing bursts as this would allow wallets/clients to execute multiple requests in parallel. I don't think this is an issue, but this could result in a different CPU load patterns and should be taken into consideration.
Arc<Header>
and pass block around w/o an arcBlueWorkType
to Uint192blocked by #53
In order to make nodes have as precise a time as possible and to increase the number of honest nodes reporting a correct time in their blocks, either:
Maybe for this purpose implement a time server into the Kaspa DNS servers functionality, to a) decrease the internet time servers load and 2) to increase the chance of having the source of correct time in the case of time servers being firewalled out.
Probably (for a case when there are multiple nodes behind a firewall for redundancy, most of which are only aware of each other, and only 1 of them have the full internet access) also implement a time server functionality into the nodes p2p protocol as a fallback and last resort option.
Go over all TODOs and fix any TODO that is necessary for the official release
Address all unresolved comments on #118 and cover txscript with many tests: Each opcode has to be tested
Blocked by #50
This issue being opened to brainstorm possible use cases which "could" become possible if there was a layer bridging internet packets into the browser.
Link to starting discord convo:
https://discord.com/channels/599153230659846165/1001242675942531132/1059520395721584670
Generally we should check which bucket takes the most space and consider storing it outside the main db
Describe the bug
Was using the Build.ps1 in the \rusty-kaspa\kos\ directory and noticed the following...
& "wasm-pack build --dev --target web --out-name kaspa --out-dir app/wasm"
& "wasm-pack" build --dev --target web --out-name kaspa --out-dir app/wasm
I think it's because PowerShell treats everything inside the quote as a single command. Parameters should follow the quotes. These quotes will need to change on all wasm-pack commands. The above is just a single example.
To Reproduce
Steps to reproduce the behavior:
1,) install prerequisites from "https://github.com/kaspanet/rusty-kaspa#readme"
2.) Verify that the running of scripts is allowed on your system and if not, use the Set-ExecutionPolicy command to allow them per your system security requirements.
3.) Perform the following from elevated PowerShell Window
git clone https://github.com/kaspanet/rusty-kaspa
cd .\rusty-kaspa\kos
.\build.ps1
Expected behavior
The .\build.ps1 script should begin to build the solution, instead of erroring out due to an invalid command.
Screenshots
Desktop (please complete the following information):
I would like to transfer the following issue to the rusty-kaspa
repo:
Currently, many nodes have RPC ports potentially open to the world
Some manner of authentication should be implemented to mitigate itSuggested solution: gRPC supports authentication out-of-the-box: https://grpc.io/docs/guides/auth/
Source: kaspanet/kaspad#1893
Only the auth method should probably ideally support wRPC, gRPC and all potential future protocols in a generic manner.
available in The LLVM Compiler Infrastructure (https://llvm.org/)
The append only code should throw an error if the same key is inserted twice.
The only exception for such code is if the store has additional compact data form.
Describe the bug
If a Windows user is starting from a clean system, git for windows will not be present and when a user executes the git command to clone the repo, it will fail
To Reproduce
Steps to reproduce the behavior:
Start from a clean Windows OS, follow the Getting Started section in the readme file exactly "https://github.com/kaspanet/rusty-kaspa#getting-started" and when you try to run "git clone https://github.com/kaspanet/rusty-kaspa" it will fail.
Expected behavior
When starting from a clean install of Windows OS and following the Getting Started section in the readme file exactly "https://github.com/kaspanet/rusty-kaspa#getting-started", executing "git clone https://github.com/kaspanet/rusty-kaspa" should succeed and clone the repo to the local directory.
Perhaps adding a section after the "Install the rust toolchain" step to install "Git for Windows". This would be an ideal place to put this step, as the "Install the rust toolchain" step does allow for the automatic installation of Visual Studio. Git for Windows can be installed using the "Visual Studio Installer". Once Visual Studio is installed, simply navigate to the Windows start menu, locate the "Visual Studio Installer" and open it. Once the Visual Studio Installer menu has appeared, select "Modify". On the next menu, select the tab "Individual Components" and search for "git"
Check the check box for "Git for Windows" and install.
Desktop (please complete the following information):
Blocked by #50
The Kaspa cryptocurrency project launched in November 2021, and is growing quickly.
It is a community governed OSS project.
Kaspa's value proposition is to fulfil Satoshi Nakamoto's original vision with Bitcoin, to become a peer to peer electronic cash system. Kaspa is powered by a proof of work network of miners that produce 1 block per second, onto a blockDAG governed by the GHOSTDAG consensus engine. It is under the final stages to upgrade the network to 32 blocks per second by rewriting the peer to peer network node in rustlang. This allows Kaspa to scale down confirmation times to several seconds.
The outcome is a currency that is as secure as Bitcoin under similar network hashrate or more secure considering Kaspa doesn't orphan blocks, as decentralized as Bitcoin or more considering the block rewards are much more granular than Bitcoin making solo-mining more viable, and much more usable as a medium of exchange than Bitcoin considering the network can house at least 8,000 transactions each second, and those transactions can get settled on the network with probabilistic finality in a scale of seconds, eliminating long wait times.
As of writing these lines, Kaspa has a $130.8M market cap, a $224.5M fully dilluted market cap, and $2.7M daily volume.
Kaspa has several different self-custidy wallets developed by different community members:
There are projects for adding support of Kaspa by hardware wallets such as Ledger, Tangem, and OneKey.
Finally there are custodial wallets for community memberrs to tip each other on Discord and Telegram.
There is a need to establish a standard scheme for sending Kaspa currency between all wallets.
In order to establish a standard, I propose to register a scheme in accordance with IANA URI Schema RFC 7595 as described in Section 7.2 Registration Process.
Scheme name:
kaspa
Status:
Provisional
Applications/protocols that use this scheme name:
Transfer of Kaspa coins, marked as $KAS, by Wallets that
implement the Kaspa protocols.
Contact:
Registegin party: Eyal Yablonka <[email protected]>;
Eyal Yablonka <[email protected]>
Scheme creator: Kaspa URI Scheme
Change controller:
Either the registering party or someone who is verified to
represent the scheme creator. See previous answer.
E.g.: Kaspa core developers.
References:
[1] https://github.com/kaspanet/kaspad
[2] https://kaspawiki.net
[3] https://discord.gg/kaspa
[4] https://kaspa.org
Scheme syntax:
kaspa:<bech32_address>[?[amount=<size>][&][label=<label>][&][message=<message>][&][payload=<payload_hex>]]
Example:
kaspa:qpqtq6r0r0v2mwm4txcd756m27lm33azq5f7epyhgl5tyjny5et854lazvrjn?amount=0.12345678&label=label&message=message&payload=1A2B3C4D5E6F
Scheme semantics:
Send money to a Kaspa address.
Encoding considerations:
The address is bech32 encoded.
The payload is hex encoded.
The labels and message are utf-8 encoded.
Interoperability considerations:
None.
Security considerations:
None.
When pre-approved by Kaspa core developers and wallet developers, this proposal should be sent to [email protected]
Existing schemes: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
Bitcoin scheme: https://www.iana.org/assignments/uri-schemes/prov/bitcoin
Bitcoin Cash scheme: https://www.iana.org/assignments/uri-schemes/prov/bitcoincash
Registration process: https://www.rfc-editor.org/rfc/rfc7595.html#section-7.2
Describe the bug
When using \rusty-kaspa\kos\Build.ps1, the build errors out as it is not able to find "clang", even though LLVM is installed. I had to add "C:\Program Files\LLVM\bin" directly to the Path environment variable and reboot or the build process couldn't find clang. This is not mentioned in the Readme...it says only to "set LIBCLANG_PATH env var pointing to the bin dir of the llvm installation" and I did already have the LIBCLANG_PATH set. Once I added "C:\Program Files\LLVM\bin" to the "Path" environment variable and rebooted, it was able to find clang and proceed.
To Reproduce
Steps to reproduce the behavior:
Starting from a clean install of Windows, follow the Kaspa Readme to install prerequisites and clone the rusty-kaspa directory.
Navigate down to the rusty-kaspa/kos directory and open an elevated PowerShell window at this location. execute \rusty-kaspa\kos\Build.ps1 after applying the fix discussed in issue "#245"
the script should fail as it cannot find "clang"
Expected behavior
When executing \rusty-kaspa\kos\Build.ps1, it should build successfully.
Desktop (please complete the following information):
Additional context
Add any other context about the problem here.
lmdb vs rocksdb and more
An issue for gathering any possible feature wished to be implemented during the rewrite of Kaspa to Rust. This might help guiding the developers to design things in a specific way, even if the actual feature is yet to be implemented.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.