qweb3 1.1.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- qweb3-1.1.0/LICENSE +110 -0
- qweb3-1.1.0/PKG-INFO +75 -0
- qweb3-1.1.0/README.md +60 -0
- qweb3-1.1.0/pyproject.toml +26 -0
- qweb3-1.1.0/qweb3/__init__.py +107 -0
- qweb3-1.1.0/qweb3/_keccak.py +73 -0
- qweb3-1.1.0/qweb3/abi.py +341 -0
- qweb3-1.1.0/qweb3/batch.py +97 -0
- qweb3-1.1.0/qweb3/bech32m.py +88 -0
- qweb3-1.1.0/qweb3/cli.py +168 -0
- qweb3-1.1.0/qweb3/contract.py +176 -0
- qweb3-1.1.0/qweb3/crypto_backend.py +46 -0
- qweb3-1.1.0/qweb3/errors.py +53 -0
- qweb3-1.1.0/qweb3/fee.py +131 -0
- qweb3-1.1.0/qweb3/hooks.py +205 -0
- qweb3-1.1.0/qweb3/qns.py +126 -0
- qweb3-1.1.0/qweb3/rest.py +154 -0
- qweb3-1.1.0/qweb3/rpc.py +139 -0
- qweb3-1.1.0/qweb3/signer.py +63 -0
- qweb3-1.1.0/qweb3/utils.py +256 -0
- qweb3-1.1.0/qweb3/wallet.py +142 -0
- qweb3-1.1.0/qweb3.egg-info/PKG-INFO +75 -0
- qweb3-1.1.0/qweb3.egg-info/SOURCES.txt +27 -0
- qweb3-1.1.0/qweb3.egg-info/dependency_links.txt +1 -0
- qweb3-1.1.0/qweb3.egg-info/entry_points.txt +2 -0
- qweb3-1.1.0/qweb3.egg-info/requires.txt +2 -0
- qweb3-1.1.0/qweb3.egg-info/top_level.txt +1 -0
- qweb3-1.1.0/setup.cfg +4 -0
- qweb3-1.1.0/tests/test_offline.py +307 -0
qweb3-1.1.0/LICENSE
ADDED
|
@@ -0,0 +1,110 @@
|
|
|
1
|
+
# Quantova Licensing Overview
|
|
2
|
+
|
|
3
|
+
**Repository:** `qweb3.py` — Quantova Post-Quantum Web3 Client SDK (Python)
|
|
4
|
+
|
|
5
|
+
This repository contains software and documentation developed and maintained by Quantova Inc. This file serves as the authoritative licensing index for the contents of this repository and applies to all contents of this repository unless explicitly stated otherwise. It is published in alignment with the licensing standard of the wider Quantova technology stack.
|
|
6
|
+
|
|
7
|
+
## Copyright and Ownership
|
|
8
|
+
|
|
9
|
+
© 2026 Quantova Inc. All rights reserved.
|
|
10
|
+
|
|
11
|
+
Quantova Inc is a company registered in Singapore and is the legal owner and steward of:
|
|
12
|
+
|
|
13
|
+
- The Quantova protocol
|
|
14
|
+
- The QRC20 network standards
|
|
15
|
+
- The Quantova Virtual Machine (QVM)
|
|
16
|
+
- The Provenance and Quantization Registry (PQR)
|
|
17
|
+
- Associated research, specifications, client libraries, and reference implementations
|
|
18
|
+
|
|
19
|
+
`qweb3.py` is the official Python client SDK for the Quantova network and forms part of this stack.
|
|
20
|
+
|
|
21
|
+
## Primary License: Business Source License (BUSL-1.1)
|
|
22
|
+
|
|
23
|
+
Unless otherwise stated, all contents of this repository — including the SDK source code, reference implementations, examples, and documentation — are licensed under the Business Source License, version 1.1 (BUSL-1.1).
|
|
24
|
+
|
|
25
|
+
The full license text is included in this repository at:
|
|
26
|
+
|
|
27
|
+
```
|
|
28
|
+
/LICENSE-BUSL-1.1
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
The authoritative BUSL-1.1 license text may also be obtained from: https://mariadb.com/bsl11/
|
|
32
|
+
|
|
33
|
+
Key parameters for this repository:
|
|
34
|
+
|
|
35
|
+
- **Licensor:** Quantova Inc.
|
|
36
|
+
- **Licensed Work:** `qweb3.py` — Quantova Post-Quantum Web3 Client SDK, © 2026 Quantova Inc.
|
|
37
|
+
- **Change Date:** 2029-06-01 (or the fourth anniversary of the first public distribution of a given version, whichever comes first).
|
|
38
|
+
- **Change License:** Apache License, Version 2.0.
|
|
39
|
+
|
|
40
|
+
On the Change Date, each version of the Licensed Work converts automatically to the Change License.
|
|
41
|
+
|
|
42
|
+
## What This Repository Contains
|
|
43
|
+
|
|
44
|
+
This repository provides the client-side developer SDK used to interact with the canonical Quantova network: post-quantum key generation and signing (Falcon, Dilithium, SPHINCS+), the `q_*` JSON-RPC client, the QVM contract layer (Solidity ABI encoding/decoding and event-log decoding), QNS `.q` name resolution, fee and gas estimation, batch requests, event hooks, a REST gateway client, and the `qweb3-cli` toolbelt. It does not contain Quantova consensus, runtime, or node implementation code.
|
|
45
|
+
|
|
46
|
+
## Application and Integration Clarification
|
|
47
|
+
|
|
48
|
+
Building applications, wallets, services, dashboards, integrations, and developer tooling on top of this SDK that interact with the canonical Quantova network is explicitly permitted under the BUSL-1.1 license and does not constitute restricted "Production Use." Using this SDK to submit transactions, query state, manage keys, and operate infrastructure on the Quantova network does not create additional licensing obligations.
|
|
49
|
+
|
|
50
|
+
## Validator and Node Operator Clarification
|
|
51
|
+
|
|
52
|
+
Running a validator node or full node on the canonical Quantova network, and using this SDK to support such operation, is explicitly permitted under the BUSL-1.1 license and does not constitute restricted "Production Use."
|
|
53
|
+
|
|
54
|
+
A formal clarification for validators, node operators, exchanges, custodians, and infrastructure providers is provided at:
|
|
55
|
+
|
|
56
|
+
```
|
|
57
|
+
/docs/validators/licensing.md
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
Participation in staking, consensus, block production, and transaction processing on the Quantova network does not create additional licensing obligations.
|
|
61
|
+
|
|
62
|
+
## Restricted Use Under BUSL-1.1
|
|
63
|
+
|
|
64
|
+
The BUSL-1.1 license restricts use of the Licensed Work, together with Quantova consensus, runtime, and QVM code, to launch, operate, or market a competing blockchain network or distributed ledger that is not the canonical Quantova network. It further restricts offering the Licensed Work to third parties as a hosted or managed service, or otherwise using the Licensed Work to provide a commercial product or service that competes with the products or services of the Licensor.
|
|
65
|
+
|
|
66
|
+
This restriction applies to, but is not limited to:
|
|
67
|
+
|
|
68
|
+
- Independent or derivative mainnets
|
|
69
|
+
- Forks marketed as separate networks
|
|
70
|
+
- Networks intended to replace or compete with Quantova
|
|
71
|
+
- SDK distributions repackaged or offered as a competing managed service
|
|
72
|
+
|
|
73
|
+
Forking, modifying, or analyzing the code for testing, auditing, research, or contribution purposes is permitted.
|
|
74
|
+
|
|
75
|
+
## Canonical Network Definition
|
|
76
|
+
|
|
77
|
+
For licensing and authorization purposes, the canonical Quantova network is defined by all of the following:
|
|
78
|
+
|
|
79
|
+
- Official signed source releases published by Quantova Inc
|
|
80
|
+
- A unique post-quantum genesis hash
|
|
81
|
+
- Signed runtime and protocol artifacts
|
|
82
|
+
- Post-quantum cryptographic signatures, including CRYSTALS-Dilithium and Falcon
|
|
83
|
+
|
|
84
|
+
Any network deployment that does not match these identifiers is not the Quantova network and is not authorized under the Quantova BUSL license.
|
|
85
|
+
|
|
86
|
+
## Documentation and Specifications
|
|
87
|
+
|
|
88
|
+
Documentation, research materials, and protocol specifications included in this repository are licensed under BUSL-1.1 unless explicitly stated otherwise within the relevant file or directory. Documentation is provided for informational and technical reference purposes and reflects protocol behavior enforced by code.
|
|
89
|
+
|
|
90
|
+
## Third-Party Software
|
|
91
|
+
|
|
92
|
+
This repository depends on third-party open-source software. Such components remain subject to their original licenses. This includes `requests` (Apache-2.0). Post-quantum signing additionally relies on Quantova's native post-quantum crypto backend, which is distributed separately under its own Quantova license terms. Where applicable, third-party license notices are provided in:
|
|
93
|
+
|
|
94
|
+
```
|
|
95
|
+
/THIRD_PARTY_LICENSES.md
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
or within dependency manifests (for example, `pyproject.toml`).
|
|
99
|
+
|
|
100
|
+
## No Legal, Financial, or Regulatory Advice
|
|
101
|
+
|
|
102
|
+
Nothing in this repository, including documentation and specifications, constitutes legal, financial, or regulatory advice. Operators, validators, and users are responsible for ensuring compliance with applicable laws and regulations in their respective jurisdictions.
|
|
103
|
+
|
|
104
|
+
## Institutional and Licensing Inquiries
|
|
105
|
+
|
|
106
|
+
Licensing, institutional, and regulatory inquiries relating to the Quantova technology stack should be directed through official Quantova channels published by Quantova Inc.
|
|
107
|
+
|
|
108
|
+
Protocol identity and licensing intent are cryptographically anchored at genesis via an immutable on-chain commitment.
|
|
109
|
+
|
|
110
|
+
© 2026 Quantova Inc
|
qweb3-1.1.0/PKG-INFO
ADDED
|
@@ -0,0 +1,75 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: qweb3
|
|
3
|
+
Version: 1.1.0
|
|
4
|
+
Summary: Quantova Post-Quantum Web3 Client SDK (Python)
|
|
5
|
+
Author: Quantova
|
|
6
|
+
License: Apache-2.0
|
|
7
|
+
Project-URL: Homepage, https://quantova.org
|
|
8
|
+
Keywords: quantova,web3,post-quantum,blockchain,qvm,dilithium,falcon,sphincs-plus,sdk
|
|
9
|
+
Requires-Python: >=3.8
|
|
10
|
+
Description-Content-Type: text/markdown
|
|
11
|
+
License-File: LICENSE
|
|
12
|
+
Requires-Dist: requests>=2.25
|
|
13
|
+
Requires-Dist: mnemonic>=0.20
|
|
14
|
+
Dynamic: license-file
|
|
15
|
+
|
|
16
|
+
# Qweb3.py
|
|
17
|
+
|
|
18
|
+
**Quantova Post-Quantum Web3 Client — Python SDK.** Connect to a
|
|
19
|
+
[Quantova](https://quantova.org) node, manage post-quantum accounts, sign and
|
|
20
|
+
broadcast transactions, and interact with QVM smart contracts from Python. The Python
|
|
21
|
+
counterpart of [qweb3.js](https://github.com/Quantova/Qweb3.js) and
|
|
22
|
+
[qweb3.rs](https://github.com/Quantova/qweb3.rs).
|
|
23
|
+
|
|
24
|
+
## Quantum security
|
|
25
|
+
Quantova is a post-quantum Layer-1. Accounts use **NIST post-quantum signatures**
|
|
26
|
+
(**Falcon-512**, **SPHINCS+ SHAKE-128s**, **CRYSTALS-Dilithium2/ML-DSA-44**) with
|
|
27
|
+
**SHA3-256** — no ECDSA/secp256k1 — so they resist quantum attacks. Addresses are
|
|
28
|
+
**Bech32m `Q1...`**; the chain speaks **`q_*` JSON-RPC**.
|
|
29
|
+
|
|
30
|
+
## Cross-SDK compatibility (byte-for-byte)
|
|
31
|
+
Accounts derive identically to qweb3.js and qweb3.rs, so **the same mnemonic yields the
|
|
32
|
+
same `Q1...` address** in all three SDKs:
|
|
33
|
+
|
|
34
|
+
- mnemonic -> 32-byte seed = substrate mini-secret
|
|
35
|
+
`PBKDF2-HMAC-SHA512(BIP-39 entropy, "mnemonic", 2048)[:32]` — *verified* equal to
|
|
36
|
+
qweb3.js (`"test test ... junk"` -> `4ca479f5...3b4709c`).
|
|
37
|
+
- address = `SHA3-256(public_key)[:20]` with byte 0 = `0x40`, Bech32m-encoded `Q1...`.
|
|
38
|
+
- keypairs use the **same post-quantum cores** as the node and qweb3.js: Falcon-512
|
|
39
|
+
(`ChaCha20Rng(seed)`), Dilithium2/ML-DSA-44 (`keygen_from_seed`), SPHINCS+ SHAKE-128s
|
|
40
|
+
(`blake2_256`-derived components).
|
|
41
|
+
|
|
42
|
+
## Install
|
|
43
|
+
```bash
|
|
44
|
+
pip install qweb3
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
## Post-quantum backend
|
|
48
|
+
The pure-Python package ships the full client (accounts, addresses, ABI, QNS, RPC,
|
|
49
|
+
fees, contracts) and the mnemonic/address derivation above. **Key generation and
|
|
50
|
+
signing require a post-quantum backend** exposing the falcon-wasm-style interface
|
|
51
|
+
(`<scheme>_pair_from_seed` / `_sign` / `_verify`). Register it once at startup:
|
|
52
|
+
|
|
53
|
+
```python
|
|
54
|
+
import qweb3.crypto_backend as cb
|
|
55
|
+
cb.set_backend(my_pq_backend) # adapter over the Quantova PQ cores
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
Any backend that produces the **same Falcon-512 / ML-DSA-44 / SLH-DSA-SHAKE-128s keys
|
|
59
|
+
from a seed** as qweb3.js keeps addresses and signatures cross-compatible. (The
|
|
60
|
+
recommended adapter wraps the same `fn-dsa` / `fips204` / `fips205` cores used by
|
|
61
|
+
qweb3.rs, so derivation stays byte-identical.)
|
|
62
|
+
|
|
63
|
+
## Quick start
|
|
64
|
+
```python
|
|
65
|
+
from qweb3 import QWeb3
|
|
66
|
+
q = QWeb3("https://rpc.quantova.org")
|
|
67
|
+
acct = q.wallet.import_mnemonic("test test ... junk") # -> same Q1... as qweb3.js/rs
|
|
68
|
+
print(q.rpc.get_balance(acct.address))
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
## Resources
|
|
72
|
+
- 🌐 https://quantova.org · 🔎 https://qvmscan.io · 💻 https://github.com/Quantova/Qweb3.py
|
|
73
|
+
|
|
74
|
+
## License
|
|
75
|
+
BUSL-1.1 - (c) 2026 Quantova Inc. See LICENSE.
|
qweb3-1.1.0/README.md
ADDED
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
# Qweb3.py
|
|
2
|
+
|
|
3
|
+
**Quantova Post-Quantum Web3 Client — Python SDK.** Connect to a
|
|
4
|
+
[Quantova](https://quantova.org) node, manage post-quantum accounts, sign and
|
|
5
|
+
broadcast transactions, and interact with QVM smart contracts from Python. The Python
|
|
6
|
+
counterpart of [qweb3.js](https://github.com/Quantova/Qweb3.js) and
|
|
7
|
+
[qweb3.rs](https://github.com/Quantova/qweb3.rs).
|
|
8
|
+
|
|
9
|
+
## Quantum security
|
|
10
|
+
Quantova is a post-quantum Layer-1. Accounts use **NIST post-quantum signatures**
|
|
11
|
+
(**Falcon-512**, **SPHINCS+ SHAKE-128s**, **CRYSTALS-Dilithium2/ML-DSA-44**) with
|
|
12
|
+
**SHA3-256** — no ECDSA/secp256k1 — so they resist quantum attacks. Addresses are
|
|
13
|
+
**Bech32m `Q1...`**; the chain speaks **`q_*` JSON-RPC**.
|
|
14
|
+
|
|
15
|
+
## Cross-SDK compatibility (byte-for-byte)
|
|
16
|
+
Accounts derive identically to qweb3.js and qweb3.rs, so **the same mnemonic yields the
|
|
17
|
+
same `Q1...` address** in all three SDKs:
|
|
18
|
+
|
|
19
|
+
- mnemonic -> 32-byte seed = substrate mini-secret
|
|
20
|
+
`PBKDF2-HMAC-SHA512(BIP-39 entropy, "mnemonic", 2048)[:32]` — *verified* equal to
|
|
21
|
+
qweb3.js (`"test test ... junk"` -> `4ca479f5...3b4709c`).
|
|
22
|
+
- address = `SHA3-256(public_key)[:20]` with byte 0 = `0x40`, Bech32m-encoded `Q1...`.
|
|
23
|
+
- keypairs use the **same post-quantum cores** as the node and qweb3.js: Falcon-512
|
|
24
|
+
(`ChaCha20Rng(seed)`), Dilithium2/ML-DSA-44 (`keygen_from_seed`), SPHINCS+ SHAKE-128s
|
|
25
|
+
(`blake2_256`-derived components).
|
|
26
|
+
|
|
27
|
+
## Install
|
|
28
|
+
```bash
|
|
29
|
+
pip install qweb3
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
## Post-quantum backend
|
|
33
|
+
The pure-Python package ships the full client (accounts, addresses, ABI, QNS, RPC,
|
|
34
|
+
fees, contracts) and the mnemonic/address derivation above. **Key generation and
|
|
35
|
+
signing require a post-quantum backend** exposing the falcon-wasm-style interface
|
|
36
|
+
(`<scheme>_pair_from_seed` / `_sign` / `_verify`). Register it once at startup:
|
|
37
|
+
|
|
38
|
+
```python
|
|
39
|
+
import qweb3.crypto_backend as cb
|
|
40
|
+
cb.set_backend(my_pq_backend) # adapter over the Quantova PQ cores
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
Any backend that produces the **same Falcon-512 / ML-DSA-44 / SLH-DSA-SHAKE-128s keys
|
|
44
|
+
from a seed** as qweb3.js keeps addresses and signatures cross-compatible. (The
|
|
45
|
+
recommended adapter wraps the same `fn-dsa` / `fips204` / `fips205` cores used by
|
|
46
|
+
qweb3.rs, so derivation stays byte-identical.)
|
|
47
|
+
|
|
48
|
+
## Quick start
|
|
49
|
+
```python
|
|
50
|
+
from qweb3 import QWeb3
|
|
51
|
+
q = QWeb3("https://rpc.quantova.org")
|
|
52
|
+
acct = q.wallet.import_mnemonic("test test ... junk") # -> same Q1... as qweb3.js/rs
|
|
53
|
+
print(q.rpc.get_balance(acct.address))
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
## Resources
|
|
57
|
+
- 🌐 https://quantova.org · 🔎 https://qvmscan.io · 💻 https://github.com/Quantova/Qweb3.py
|
|
58
|
+
|
|
59
|
+
## License
|
|
60
|
+
BUSL-1.1 - (c) 2026 Quantova Inc. See LICENSE.
|
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
[build-system]
|
|
2
|
+
requires = ["setuptools>=64", "wheel"]
|
|
3
|
+
build-backend = "setuptools.build_meta"
|
|
4
|
+
|
|
5
|
+
[project]
|
|
6
|
+
name = "qweb3"
|
|
7
|
+
version = "1.1.0"
|
|
8
|
+
description = "Quantova Post-Quantum Web3 Client SDK (Python)"
|
|
9
|
+
readme = "README.md"
|
|
10
|
+
requires-python = ">=3.8"
|
|
11
|
+
license = { text = "Apache-2.0" }
|
|
12
|
+
keywords = ["quantova", "web3", "post-quantum", "blockchain", "qvm", "dilithium", "falcon", "sphincs-plus", "sdk"]
|
|
13
|
+
authors = [{ name = "Quantova" }]
|
|
14
|
+
dependencies = [
|
|
15
|
+
"requests>=2.25",
|
|
16
|
+
"mnemonic>=0.20",
|
|
17
|
+
]
|
|
18
|
+
|
|
19
|
+
[project.urls]
|
|
20
|
+
Homepage = "https://quantova.org"
|
|
21
|
+
|
|
22
|
+
[project.scripts]
|
|
23
|
+
qweb3-cli = "qweb3.cli:main"
|
|
24
|
+
|
|
25
|
+
[tool.setuptools]
|
|
26
|
+
packages = ["qweb3"]
|
|
@@ -0,0 +1,107 @@
|
|
|
1
|
+
"""qweb3 — Quantova Post-Quantum Web3 Client SDK (Python).
|
|
2
|
+
|
|
3
|
+
A synchronous client for the Quantova Layer-1 blockchain: post-quantum wallets
|
|
4
|
+
and signing (Falcon, Dilithium, SPHINCS+), the full ``q_*`` JSON-RPC namespace,
|
|
5
|
+
a QVM contract layer with ABI codec and event-log decoding, QNS ``.q`` name
|
|
6
|
+
resolution, dynamic fee/gas estimation, batch requests, real-time event hooks,
|
|
7
|
+
and REST-gateway access.
|
|
8
|
+
|
|
9
|
+
Quick start::
|
|
10
|
+
|
|
11
|
+
from qweb3 import QWeb3
|
|
12
|
+
q = QWeb3("http://127.0.0.1:9944", rest_url="http://127.0.0.1:8080")
|
|
13
|
+
block = q.rpc.block_number()
|
|
14
|
+
fees = q.fees.estimate()
|
|
15
|
+
|
|
16
|
+
Post-quantum signing requires Quantova's crypto backend; install it and call
|
|
17
|
+
``qweb3.crypto_backend.set_backend(...)`` (see that module's docstring).
|
|
18
|
+
"""
|
|
19
|
+
|
|
20
|
+
from . import abi, crypto_backend
|
|
21
|
+
from .abi import (
|
|
22
|
+
decode_function_result,
|
|
23
|
+
decode_parameters,
|
|
24
|
+
encode_function_call,
|
|
25
|
+
encode_parameters,
|
|
26
|
+
event_topic,
|
|
27
|
+
function_selector,
|
|
28
|
+
)
|
|
29
|
+
from .batch import BatchRequest, BatchResult
|
|
30
|
+
from .contract import QContract
|
|
31
|
+
from .errors import (
|
|
32
|
+
ConnectionErrorQ,
|
|
33
|
+
InvalidArgumentError,
|
|
34
|
+
QWeb3Error,
|
|
35
|
+
RpcError,
|
|
36
|
+
TransactionError,
|
|
37
|
+
)
|
|
38
|
+
from .fee import FeeOracle
|
|
39
|
+
from .hooks import EventHooks, TxTracker
|
|
40
|
+
from .qns import QNS
|
|
41
|
+
from .rest import QRestClient
|
|
42
|
+
from .rpc import QRpcClient
|
|
43
|
+
from .signer import QuantumSigner
|
|
44
|
+
from .utils import AddressUtils, FormatUtils, HexUtils, ValidationUtils
|
|
45
|
+
from .wallet import Account, QuantumWallet
|
|
46
|
+
|
|
47
|
+
__version__ = "1.1.0"
|
|
48
|
+
|
|
49
|
+
|
|
50
|
+
class QWeb3:
|
|
51
|
+
"""High-level facade wiring the RPC client, wallet, fees, hooks, and helpers."""
|
|
52
|
+
|
|
53
|
+
def __init__(self, url: str = "http://127.0.0.1:9944", *,
|
|
54
|
+
rest_url: str = None, session=None) -> None:
|
|
55
|
+
self.url = url
|
|
56
|
+
self.rpc = QRpcClient(url, session=session)
|
|
57
|
+
self.rest = QRestClient(rest_url, session=session) if rest_url else None
|
|
58
|
+
self.wallet = QuantumWallet()
|
|
59
|
+
self.signer = QuantumSigner
|
|
60
|
+
self.abi = abi
|
|
61
|
+
self.fees = FeeOracle(rpc=self.rpc, rest_client=self.rest)
|
|
62
|
+
self.hooks = EventHooks(rpc=self.rpc, rest_client=self.rest)
|
|
63
|
+
|
|
64
|
+
def contract(self, abi_list, address: str) -> QContract:
|
|
65
|
+
return QContract(abi_list, address, rpc=self.rpc, wallet=self.wallet, rest_client=self.rest)
|
|
66
|
+
|
|
67
|
+
def qns(self, registry_address: str, **kwargs) -> QNS:
|
|
68
|
+
return QNS(registry_address, rpc=self.rpc, wallet=self.wallet,
|
|
69
|
+
rest_client=self.rest, **kwargs)
|
|
70
|
+
|
|
71
|
+
def batch(self) -> BatchRequest:
|
|
72
|
+
return BatchRequest(self.url)
|
|
73
|
+
|
|
74
|
+
|
|
75
|
+
__all__ = [
|
|
76
|
+
"QWeb3",
|
|
77
|
+
"QRpcClient",
|
|
78
|
+
"QRestClient",
|
|
79
|
+
"QuantumWallet",
|
|
80
|
+
"Account",
|
|
81
|
+
"QuantumSigner",
|
|
82
|
+
"QContract",
|
|
83
|
+
"QNS",
|
|
84
|
+
"BatchRequest",
|
|
85
|
+
"BatchResult",
|
|
86
|
+
"FeeOracle",
|
|
87
|
+
"EventHooks",
|
|
88
|
+
"TxTracker",
|
|
89
|
+
"AddressUtils",
|
|
90
|
+
"HexUtils",
|
|
91
|
+
"FormatUtils",
|
|
92
|
+
"ValidationUtils",
|
|
93
|
+
"QWeb3Error",
|
|
94
|
+
"ConnectionErrorQ",
|
|
95
|
+
"InvalidArgumentError",
|
|
96
|
+
"RpcError",
|
|
97
|
+
"TransactionError",
|
|
98
|
+
"abi",
|
|
99
|
+
"crypto_backend",
|
|
100
|
+
"function_selector",
|
|
101
|
+
"event_topic",
|
|
102
|
+
"encode_parameters",
|
|
103
|
+
"decode_parameters",
|
|
104
|
+
"encode_function_call",
|
|
105
|
+
"decode_function_result",
|
|
106
|
+
"__version__",
|
|
107
|
+
]
|
|
@@ -0,0 +1,73 @@
|
|
|
1
|
+
"""Pure-Python keccak-256 (Ethereum/Solidity padding, 0x01).
|
|
2
|
+
|
|
3
|
+
This is the default selector/topic hash used by the QVM ABI codec, which speaks
|
|
4
|
+
the standard Solidity ABI. It is dependency-free so the codec works out of the
|
|
5
|
+
box; it can be overridden via ``qweb3.abi.set_keccak`` (for example to use a
|
|
6
|
+
faster C implementation, or the hash provided by Quantova's crypto backend).
|
|
7
|
+
|
|
8
|
+
Note: this is keccak-256, not SHA3-256. They differ only in the padding byte.
|
|
9
|
+
Quantova hashes *transactions/state* with SHA3-256 (handled in the signing
|
|
10
|
+
layer); contract-call *selectors* use keccak-256, which is what this provides.
|
|
11
|
+
"""
|
|
12
|
+
|
|
13
|
+
from typing import List
|
|
14
|
+
|
|
15
|
+
_RC = [
|
|
16
|
+
0x0000000000000001, 0x0000000000008082, 0x800000000000808A, 0x8000000080008000,
|
|
17
|
+
0x000000000000808B, 0x0000000080000001, 0x8000000080008081, 0x8000000000008009,
|
|
18
|
+
0x000000000000008A, 0x0000000000000088, 0x0000000080008009, 0x000000008000000A,
|
|
19
|
+
0x000000008000808B, 0x800000000000008B, 0x8000000000008089, 0x8000000000008003,
|
|
20
|
+
0x8000000000008002, 0x8000000000000080, 0x000000000000800A, 0x800000008000000A,
|
|
21
|
+
0x8000000080008081, 0x8000000000008080, 0x0000000080000001, 0x8000000080008008,
|
|
22
|
+
]
|
|
23
|
+
_ROT = [
|
|
24
|
+
[0, 36, 3, 41, 18],
|
|
25
|
+
[1, 44, 10, 45, 2],
|
|
26
|
+
[62, 6, 43, 15, 61],
|
|
27
|
+
[28, 55, 25, 21, 56],
|
|
28
|
+
[27, 20, 39, 8, 14],
|
|
29
|
+
]
|
|
30
|
+
_MASK = (1 << 64) - 1
|
|
31
|
+
|
|
32
|
+
|
|
33
|
+
def _rotl(x: int, n: int) -> int:
|
|
34
|
+
return ((x << n) | (x >> (64 - n))) & _MASK
|
|
35
|
+
|
|
36
|
+
|
|
37
|
+
def _keccak_f(s: List[List[int]]) -> None:
|
|
38
|
+
for rnd in range(24):
|
|
39
|
+
c = [s[x][0] ^ s[x][1] ^ s[x][2] ^ s[x][3] ^ s[x][4] for x in range(5)]
|
|
40
|
+
d = [c[(x + 4) % 5] ^ _rotl(c[(x + 1) % 5], 1) for x in range(5)]
|
|
41
|
+
for x in range(5):
|
|
42
|
+
for y in range(5):
|
|
43
|
+
s[x][y] ^= d[x]
|
|
44
|
+
b = [[0] * 5 for _ in range(5)]
|
|
45
|
+
for x in range(5):
|
|
46
|
+
for y in range(5):
|
|
47
|
+
b[y][(2 * x + 3 * y) % 5] = _rotl(s[x][y], _ROT[x][y])
|
|
48
|
+
for x in range(5):
|
|
49
|
+
for y in range(5):
|
|
50
|
+
s[x][y] = (b[x][y] ^ ((~b[(x + 1) % 5][y]) & b[(x + 2) % 5][y])) & _MASK
|
|
51
|
+
s[0][0] ^= _RC[rnd]
|
|
52
|
+
|
|
53
|
+
|
|
54
|
+
def keccak256(data: bytes) -> bytes:
|
|
55
|
+
"""Return the 32-byte keccak-256 digest of ``data``."""
|
|
56
|
+
rate = 136 # bytes for keccak-256
|
|
57
|
+
msg = bytearray(data)
|
|
58
|
+
pad_len = rate - (len(msg) % rate)
|
|
59
|
+
msg += bytearray(pad_len)
|
|
60
|
+
msg[len(data)] ^= 0x01 # keccak padding (Ethereum/Solidity)
|
|
61
|
+
msg[-1] ^= 0x80
|
|
62
|
+
|
|
63
|
+
s = [[0] * 5 for _ in range(5)]
|
|
64
|
+
for off in range(0, len(msg), rate):
|
|
65
|
+
for i in range(rate // 8):
|
|
66
|
+
lane = int.from_bytes(msg[off + i * 8: off + i * 8 + 8], "little")
|
|
67
|
+
s[i % 5][i // 5] ^= lane
|
|
68
|
+
_keccak_f(s)
|
|
69
|
+
|
|
70
|
+
out = bytearray()
|
|
71
|
+
for i in range(4): # 4 lanes * 8 bytes = 32 bytes
|
|
72
|
+
out += (s[i % 5][i // 5]).to_bytes(8, "little")
|
|
73
|
+
return bytes(out)
|