Adjust for 3.0 (#32)

* adjust for 3.0

* fix

* fix

* Add PlonkVerifierHelper lib description

---------

Co-authored-by: Oleh Komendant <[email protected]>

Author: Arvolear

docs/getting-started/Overview.md

@@ -2,53 +2,101 @@
 
 <img src={require("/static/img/docs/solarity.png").default} alt=""/>
 
-## Solidity Library for Savvies by Distributed Lab
-
-The library consists of modules and utilities that are built leveraging [Openzeppelin Contracts](https://github.com/OpenZeppelin/openzeppelin-contracts) (4.9.6) and **go far beyond mediocre solidity**.
+## Solarity Solidity Library
+
+Solidity contracts and utilities that **go far beyond mediocre solidity**.
+
+### Contracts
+
+```ml
+contracts
+├── access
+│   ├── AMerkleWhitelisted — "Whitelists via Merkle proofs"
+│   ├── AMultiOwnable — "Multiple owners with the equal access level"
+│   ├── ARBAC — "A powerful implementation of a true RBAC"
+│   └── extensions
+│       └── ARBACGroupable — "Groupable extension of ARBAC"
+├── contracts—registry
+│   ├── AContractsRegistry — "Reference registry implementation of ERC-6224 pattern"
+│   ├── ADependant — "Reference dependant implementation of ERC-6224 pattern"
+│   └── pools
+│       ├── APoolContractsRegistry — "Adaptation of ERC-6224 for factory-like contracts"
+│       └── APoolFactory — "Factory implementation for a pooled registry"
+├── diamond
+│   ├── ADiamondStorage — "The storage part of ERC-2535 diamond"
+│   ├── Diamond — "Revised ERC-2535 diamond implementation"
+│   └── utils
+│       ├── AInitializableStorage — "Initializable logic for diamond facets"
+│       └── DiamondERC165 — "ERC-165 introspection for diamond facets"
+├── finance
+│   ├── compound—rate—keeper
+│   │   └── ACompoundRateKeeper — "Complex percentage calculator used in lending protocols"
+│   ├── staking
+│   │   ├── AStaking — "Flexible rewards staking implementation"
+│   │   └── AValueDistributor — "Efficient distribution algorithm implementation"
+│   └── vesting
+│       └── AVesting — "Linear and exponential vesting implementation"
+├── libs
+│   ├── arrays
+│   │   ├── ArrayHelper — "Common functions to work with arrays"
+│   │   ├── Paginator — "Return array slices from view function"
+│   │   └── SetHelper — "Array abstraction over sets"
+│   ├── bn
+│   │   └── U512 — "A hyperoptimized uint512 implementation"
+│   ├── crypto
+│   │   ├── ECDSA256 — "ECDSA verification over any 256-bit curves"
+│   │   ├── ECDSA384 — "ECDSA verification over any 384-bit curves"
+│   │   ├── ECDSA512 — "ECDSA verification over any 512-bit curves"
+│   │   └── RSASSAPSS — "RSASSA-PSS verification with MGF1"
+│   ├── data—structures
+│   │   ├── AvlTree — "AVL tree implementation with an iterator traversal"
+│   │   ├── CartesianMerkleTree — "CMT reference implementation"
+│   │   ├── DynamicSet — "Set for strings and bytes"
+│   │   ├── IncrementalMerkleTree — "IMT implementation with flexible tree height"
+│   │   ├── PriorityQueue — "Max queue heap implementation"
+│   │   ├── SparseMerkleTree — "SMT optimized implementation"
+│   │   └── memory
+│   │       └── Vector — "A pushable memory array"
+│   ├── utils
+│   │   ├── DecimalsConverter — "Simplify interaction with ERC-20 decimals"
+│   │   ├── MemoryUtils — "Functions for memory manipulation"
+│   │   ├── ReturnDataProxy — "Bypass extra returndata copy when returning data"
+│   │   └── Typecaster — "Cast between various Solidity types"
+│   └── zkp
+│       ├── Groth16VerifierHelper — "Simplify integration with Groth16 proofs"
+│       └── PlonkVerifierHelper — "Simplify integration with Plonk proofs"
+├── oracles
+│   ├── AUniswapV2Oracle — "Uniswap V2 oracle with custom TWAP"
+│   └── UniswapV3Oracle — "Uniswap V3 oracle with a clean interface"
+├── proxy
+│   └── adminable
+│       ├── AdminableProxy — "A slight modification of a transparent proxy"
+│       └── AdminableProxyUpgrader — "A slight modification of a proxy admin"
+├── tokens
+│   └── ASBT — "A minimal implementation of an SBT"
+├── utils
+│   ├── ABlockGuard — "Protect against flashloans"
+│   └── Globals — "Some commonly used constants"
+├── presets — "Presets for the library contracts"
+├── interfaces — "Interfaces for the library contracts"
+└── mock — "Mocks for testing purposes"
+```
 
-* Implementation of the [**Contracts Registry**](https://eips.ethereum.org/EIPS/eip-6224) pattern
-* State-of-the-art cryptography primitives (**ECDSA over 256-bit and 384-bit curves**, **RSASSA-PSS**)
-* Advanced data structures (**Vector**, **DynamicSet**, **PriorityQueue**, **AVLTree**)
-* ZK-friendly [**Sparse Merkle Tree**](https://docs.iden3.io/publications/pdfs/Merkle-Tree.pdf) and [**Incremental Merkle Tree**](https://github.com/runtimeverification/deposit-contract-verification/blob/master/deposit-contract-verification.pdf) implementations
-* Versatile **RBAC** and **MultiOwnable** smart contracts
-* Enhanced and simplified [**Diamond**](https://eips.ethereum.org/EIPS/eip-2535) pattern
-* Flexible finance instruments (**Staking**, **Vesting**)
-* Novel **ReturnDataProxy** contract
-* Robust UniswapV2 and UniswapV3 oracles
-* Lightweight **SBT** implementation
-* Utilities to ease work with memory, types, ERC20 decimals, arrays, sets, and ZK proofs
+Built with courage and aspiration to perfection.
 
-Checkout guides section for detailed explanations with usage examples for each module.
+> The library is designed to work cohesively with [hardhat-zkit](https://github.com/dl-solarity/hardhat-zkit) and [circom-lib](https://github.com/dl-solarity/circom-lib) packages.
 
 ### Installation
 
 ```bash
-$ npm install @solarity/solidity-lib
+npm install @solarity/solidity-lib
 ```
 
 The latest stable version is always in the `master` branch.
 
-### Usage
-
-You will find the smart contracts in the `contracts` directory. Feel free to play around and check the source code, it is rather descriptive.
-
-Once the [npm package](https://www.npmjs.com/package/@solarity/solidity-lib) is installed, one can use the library just like that:
-
-```solidity
-pragma solidity ^0.8.4;
-
-import "@solarity/solidity-lib/contracts-registry/presets/OwnableContractsRegistry.sol";
-
-contract ContractsRegistry is OwnableContractsRegistry {
-    . . .
-}
-```
-
-> It is important to use the library as it is shipped and not copy-paste the code from untrusted sources.
-
 ### Contribution
 
-We are open to contributions to our [solidity-lib](https://github.com/dl-solarity/solidity-lib/tree/master) repository. If you're interested in contributing, please visit the [How to contribute](./contribution/how-to-contribute.md) section.
+We are open to any mind-blowing ideas! Please take a look at our [contribution guidelines](https://docs.solarity.dev/docs/getting-started/contribution/how-to-contribute) to get involved.
 
 ### License
 

docs/getting-started/contribution/solidity.md

@@ -575,13 +575,13 @@ All our contracts are under the MIT License. This ensures that they can be freel
 
 #### 6.2 Solidity version
 
-Use Solidity version 0.8.4. Exceptions for specific integrations are possible but must be discussed on a case-by-case basis.
+Use Solidity version 0.8.21. Exceptions for specific integrations are possible but must be discussed on a case-by-case basis.
 
 <Tabs>
 <TabItem value="good" label="Good" default>
 
 ```solidity
-pragma solidity ^0.8.4;
+pragma solidity ^0.8.21;
 ```
 
 </TabItem>

docs/getting-started/guides/access/merkle-whitelisted.md

@@ -10,18 +10,19 @@ The Merkle Whitelisted module is an abstract utility used in modules that requir
 
 The Merkle tree enables efficient validation of huge whitelists due to its logarithmic complexity. Whitelist data or user addresses are stored in the leaves, **with only the tree root saved on-chain**. This approach is cost-effective for large lists but incurs overhead for off-chain Merkle Proof generation and membership verification.
 
-The `MerkleWhitelisted` is an abstract contract that implements whitelisting logic using the Merkle Tree data structure. To validate whitelist membership, the leaf (whitelist element) and the corresponding branch (proof) are passed to the validation function to check for matching roots, indicating whitelist membership.
+The `AMerkleWhitelisted` is an abstract contract that implements whitelisting logic using the Merkle Tree data structure. To validate whitelist membership, the leaf (whitelist element) and the corresponding branch (proof) are passed to the validation function to check for matching roots, indicating whitelist membership.
 
 ## Example
 
-Start by creating a utility contract that inherits the functionalities of `MerkleWhitelisted`. The contract includes the `protectedFunctionUser` method that is restricted to whitelisted addresses. Alongside this, the contract has the `setMerkleRoot` method for setting and updating Merkle tree roots, access to which is also restricted by the `PermanentOwnable` contract.
+Start by creating a utility contract that inherits the functionalities of `AMerkleWhitelisted`. The contract includes the `protectedFunctionUser` method that is restricted to whitelisted addresses. Alongside this, the contract has the `setMerkleRoot` method for setting and updating Merkle tree roots, access to which is also restricted by the `Ownable` contract.
 
 ```solidity
-import "@solarity/solidity-lib/access-control/MerkleWhitelisted.sol";
-import "@solarity/solidity-lib/access-control/PermanentOwnable.sol";
+import "@openzeppelin/contracts/access/Ownable.sol";
 
-contract MerkleProtectedContract is MerkleWhitelisted, PermanentOwnable {
-    constructor() PermanentOwnable(msg.sender) {}
+import "@solarity/solidity-lib/access-control/AMerkleWhitelisted.sol";
+
+contract MerkleProtectedContract is AMerkleWhitelisted, Ownable {
+    constructor() Ownable(msg.sender) {}
 
     function setMerkleRoot(bytes32 merkleRoot_) external onlyOwner {
         _setMerkleRoot(merkleRoot_);

docs/getting-started/guides/access/multi-ownable.md

@@ -2,20 +2,22 @@
 
 ## Introduction
 
-The concept of the Multi Owanable module is not different from the [OpenZeppelin's Ownable contract](https://docs.openzeppelin.com/contracts/5.x/api/access#Ownable), with the exception that instead of one address as owner, a set of addresses is maintained.
+The concept of the Multi Ownable module is not different from the [OpenZeppelin's Ownable contract](https://docs.openzeppelin.com/contracts/5.x/api/access#Ownable), with the exception that instead of one address as owner, a set of addresses is maintained.
 
 ## Implementation
 
-The `MultiOwnable` contract provides a basic access control mechanism, where a list of owner addresses is granted exclusive access to specific functions. All owners have equal access rights, allowing them to add or remove other owners, including themselves. The one who calls the `__MultiOwnable_init` function (i.e., the contract deployer) will become the initial owner of the contract. This module makes the `onlyOwner` modifier available, which can be applied to functions to restrict their use to the owners.
+The `AMultiOwnable` contract provides a basic access control mechanism, where a list of owner addresses is granted exclusive access to specific functions. All owners have equal access rights, allowing them to add or remove other owners, including themselves. The one who calls the `__AMultiOwnable_init` function (i.e., the contract deployer) will become the initial owner of the contract. This module makes the `onlyOwner` modifier available, which can be applied to functions to restrict their use to the owners.
 
 ## Example
 
-Begin by creating a protected contract by inheriting it from the `MultiOwnable`.
+Begin by creating a protected contract by inheriting it from the `AMultiOwnable`.
 
 ```solidity
-contract MultiOwnableProtectedContract is MultiOwnable {
+import "@solarity/solidity-lib/access-control/AMultiOwnable.sol";
+
+contract MultiOwnableProtectedContract is AMultiOwnable {
     function __MultiOwnableProtectedContract_init() external initializer {
-        __MultiOwnable_init();
+        __AMultiOwnable_init();
     }
 
     function protectedFunction() external onlyOwner { /* ... */ }