Development Artifact Cleanup: ✅ BROTHER_NODE REORGANIZATION: Moved development test node to appropriate location - dev/test-nodes/brother_node/: Moved from root directory for better organization - Contains development configuration, test logs, and test chain data - No impact on production systems - purely development/testing artifact ✅ DEVELOPMENT ARTIFACTS IDENTIFIED: - Chain ID: aitbc-brother-chain (test/development chain) - Ports: 8010 (P2P) and 8011 (RPC) - different from production - Environment: .env file with test configuration - Logs: rpc.log and node.log from development testing session (March 15, 2026) ✅ ROOT DIRECTORY CLEANUP: Removed development clutter from production directory - brother_node/ moved to dev/test-nodes/brother_node/ - Root directory now contains only production-ready components - Development artifacts properly organized in dev/ subdirectory DIRECTORY STRUCTURE IMPROVEMENT: 📁 dev/test-nodes/: Development and testing node configurations 🏗️ Root Directory: Clean production structure with only essential components 🧪 Development Isolation: Test environments separated from production BENEFITS: ✅ Clean Production Directory: No development artifacts in root ✅ Better Organization: Development nodes grouped in dev/ subdirectory ✅ Clear Separation: Production vs development environments clearly distinguished ✅ Maintainability: Easier to identify and manage development components RESULT: Successfully moved brother_node development artifact to dev/test-nodes/ subdirectory, cleaning up the root directory while preserving development testing environment for future use.
38 lines
1.7 KiB
Solidity
Executable File
38 lines
1.7 KiB
Solidity
Executable File
// SPDX-License-Identifier: MIT
|
|
// OpenZeppelin Contracts (last updated v5.3.0) (utils/Multicall.sol)
|
|
|
|
pragma solidity ^0.8.20;
|
|
|
|
import {Address} from "./Address.sol";
|
|
import {Context} from "./Context.sol";
|
|
|
|
/**
|
|
* @dev Provides a function to batch together multiple calls in a single external call.
|
|
*
|
|
* Consider any assumption about calldata validation performed by the sender may be violated if it's not especially
|
|
* careful about sending transactions invoking {multicall}. For example, a relay address that filters function
|
|
* selectors won't filter calls nested within a {multicall} operation.
|
|
*
|
|
* NOTE: Since 5.0.1 and 4.9.4, this contract identifies non-canonical contexts (i.e. `msg.sender` is not {Context-_msgSender}).
|
|
* If a non-canonical context is identified, the following self `delegatecall` appends the last bytes of `msg.data`
|
|
* to the subcall. This makes it safe to use with {ERC2771Context}. Contexts that don't affect the resolution of
|
|
* {Context-_msgSender} are not propagated to subcalls.
|
|
*/
|
|
abstract contract Multicall is Context {
|
|
/**
|
|
* @dev Receives and executes a batch of function calls on this contract.
|
|
* @custom:oz-upgrades-unsafe-allow-reachable delegatecall
|
|
*/
|
|
function multicall(bytes[] calldata data) external virtual returns (bytes[] memory results) {
|
|
bytes memory context = msg.sender == _msgSender()
|
|
? new bytes(0)
|
|
: msg.data[msg.data.length - _contextSuffixLength():];
|
|
|
|
results = new bytes[](data.length);
|
|
for (uint256 i = 0; i < data.length; i++) {
|
|
results[i] = Address.functionDelegateCall(address(this), bytes.concat(data[i], context));
|
|
}
|
|
return results;
|
|
}
|
|
}
|