text:
compile erc20 contract error

solang: llvm/lib/IR/Instructions.cpp:1358: void llvm::StoreInst::AssertOK(): Assertion `getOperand(0)->getType() == cast(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!"' failed.
compile erc20 get error, code is here https://github.com/paritytech/pallet-contracts-waterfall/tree/master/contracts/solidity/erc20

I can reproduce this. I'm looking into it

I can reproduce this. I'm looking into it

I can reproduce this. I'm looking into it

another question, what's the address of the contract in substrate with solang?

I can reproduce this. I'm looking into it

another question, what's the address of the contract in substrate with solang?

I'm not sure where or what address you're after. If you mean the address of the current contract, you can get it with address(this). This will emit code which calls seal_address(). Is that what you are after?

I'm not sure where or what address you're after. If you mean the address of the current contract, you can get it with address(this). This will emit code which calls seal_address(). Is that what you are after?

when I call transfer function from another contract, it's always failed, the constructor input address is erc20 contract's address

pragma solidity ^0.6.0;

/**
 * @dev Interface of the ERC20 standard as defined in the EIP. Does not include
 * the optional functions; to access them see {ERC20Detailed}.
 */
interface IERC20 {
    /**
     * @dev Returns the amount of tokens in existence.
     */
    function totalSupply() external view returns (uint256);

    /**
     * @dev Returns the amount of tokens owned by `account`.
     */
    function balanceOf(address account) external view returns (uint256);

    /**
     * @dev Moves `amount` tokens from the caller's account to `recipient`.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * Emits a {Transfer} event.
     */
    function transfer(address recipient, uint256 amount) external returns (bool);

    /**
     * @dev Returns the remaining number of tokens that `spender` will be
     * allowed to spend on behalf of `owner` through {transferFrom}. This is
     * zero by default.
     *
     * This value changes when {approve} or {transferFrom} are called.
     */
    function allowance(address owner, address spender) external view returns (uint256);

    /**
     * @dev Sets `amount` as the allowance of `spender` over the caller's tokens.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * IMPORTANT: Beware that changing an allowance with this method brings the risk
     * that someone may use both the old and the new allowance by unfortunate
     * transaction ordering. One possible solution to mitigate this race
     * condition is to first reduce the spender's allowance to 0 and set the
     * desired value afterwards:
     * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
     *
     * Emits an {Approval} event.
     */
    function approve(address spender, uint256 amount) external returns (bool);

    /**
     * @dev Moves `amount` tokens from `sender` to `recipient` using the
     * allowance mechanism. `amount` is then deducted from the caller's
     * allowance.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * Emits a {Transfer} event.
     */
    function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);

    /**
     * @dev Emitted when `value` tokens are moved from one account (`from`) to
     * another (`to`).
     *
     * Note that `value` may be zero.
     */
    event Transfer(address indexed from, address indexed to, uint256 value);

    /**
     * @dev Emitted when the allowance of a `spender` for an `owner` is set by
     * a call to {approve}. `value` is the new allowance.
     */
    event Approval(address indexed owner, address indexed spender, uint256 value);
}

contract TokenTransfer{
    IERC20 public wowToken;
    constructor(address _token) public {
        wowToken = IERC20(_token);
    }

    function tokenTransfer(address _to, uint _amt) public {
        wowToken.transfer(_to,_amt);
    }
}

when I call transfer function from another contract, it's always failed, the constructor input address is erc20 contract's address

pragma solidity ^0.6.0;

/**
 * @dev Interface of the ERC20 standard as defined in the EIP. Does not include
 * the optional functions; to access them see {ERC20Detailed}.
 */
interface IERC20 {
    /**
     * @dev Returns the amount of tokens in existence.
     */
    function totalSupply() external view returns (uint256);

    /**
     * @dev Returns the amount of tokens owned by `account`.
     */
    function balanceOf(address account) external view returns (uint256);

    /**
     * @dev Moves `amount` tokens from the caller's account to `recipient`.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * Emits a {Transfer} event.
     */
    function transfer(address recipient, uint256 amount) external returns (bool);

    /**
     * @dev Returns the remaining number of tokens that `spender` will be
     * allowed to spend on behalf of `owner` through {transferFrom}. This is
     * zero by default.
     *
     * This value changes when {approve} or {transferFrom} are called.
     */
    function allowance(address owner, address spender) external view returns (uint256);

    /**
     * @dev Sets `amount` as the allowance of `spender` over the caller's tokens.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * IMPORTANT: Beware that changing an allowance with this method brings the risk
     * that someone may use both the old and the new allowance by unfortunate
     * transaction ordering. One possible solution to mitigate this race
     * condition is to first reduce the spender's allowance to 0 and set the
     * desired value afterwards:
     * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
     *
     * Emits an {Approval} event.
     */
    function approve(address spender, uint256 amount) external returns (bool);

    /**
     * @dev Moves `amount` tokens from `sender` to `recipient` using the
     * allowance mechanism. `amount` is then deducted from the caller's
     * allowance.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * Emits a {Transfer} event.
     */
    function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);

    /**
     * @dev Emitted when `value` tokens are moved from one account (`from`) to
     * another (`to`).
     *
     * Note that `value` may be zero.
     */
    event Transfer(address indexed from, address indexed to, uint256 value);

    /**
     * @dev Emitted when the allowance of a `spender` for an `owner` is set by
     * a call to {approve}. `value` is the new allowance.
     */
    event Approval(address indexed owner, address indexed spender, uint256 value);
}

contract TokenTransfer{
    IERC20 public wowToken;
    constructor(address _token) public {
        wowToken = IERC20(_token);
    }

    function tokenTransfer(address _to, uint _amt) public {
        wowToken.transfer(_to,_amt);
    }
}

I suspect the problem of transfer() failing is that the receiving contract does not have a receive() payable external {} function.
I am not sure this is the same as Ethereum Solidity, this should be checked. In Solang, a contract must have a receive() function else value transfers to it are not allowed (unless value is  sent with an external call, like foo.bar{value:102}() and this bar function is marked payable).
The rules of when value transfers are denied are not very clear when it comes to ethereum solidity.

I suspect the problem of transfer() failing is that the receiving contract does not have a receive() payable external {} function.
I am not sure this is the same as Ethereum Solidity, this should be checked. In Solang, a contract must have a receive() function else value transfers to it are not allowed (unless value is  sent with an external call, like foo.bar{value:102}() and this bar function is marked payable).
The rules of when value transfers are denied are not very clear when it comes to ethereum solidity.

The compilation issue is fixed. We now need to address the transfer() issue.
Can you please check if adding the receive() payable external {} works? Thank you.

The compilation issue is fixed. We now need to address the transfer() issue.
Can you please check if adding the receive() payable external {} works? Thank you.

So I merged another change, which should solve the issue with transfer(). Please let me know if things are working as expected now.

So I merged another change, which should solve the issue with transfer(). Please let me know if things are working as expected now.

So I merged another change, which should solve the issue with transfer(). Please let me know if things are working as expected now.

no, it's not work...

So I merged another change, which should solve the issue with transfer(). Please let me know if things are working as expected now.

no, it's not work...

Sorry I was barking up the wrong tree. Let me look at this again.

Sorry I was barking up the wrong tree. Let me look at this again.

@GalaIO can you please provide me with exact steps to reproduce please.
Thank you.

@GalaIO can you please provide me with exact steps to reproduce please.
Thank you.

@GalaIO can you please provide me with exact steps to reproduce please.
Thank you.

compile erc20.sol, and the compile TokenTransfer.sol，upload and instance in substrate, TokenTransfer contract init with erc20 contract accountId
//https://github.com/OpenZeppelin/openzeppelin-contracts

pragma solidity ^0.6.0;

/**
 * @dev Interface of the ERC20 standard as defined in the EIP. Does not include
 * the optional functions; to access them see {ERC20Detailed}.
 */
interface IERC20 {
    /**
     * @dev Returns the amount of tokens in existence.
     */
    function totalSupply() external view returns (uint256);

    /**
     * @dev Returns the amount of tokens owned by `account`.
     */
    function balanceOf(address account) external view returns (uint256);

    /**
     * @dev Moves `amount` tokens from the caller's account to `recipient`.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * Emits a {Transfer} event.
     */
    function transfer(address recipient, uint256 amount) external returns (bool);

    /**
     * @dev Returns the remaining number of tokens that `spender` will be
     * allowed to spend on behalf of `owner` through {transferFrom}. This is
     * zero by default.
     *
     * This value changes when {approve} or {transferFrom} are called.
     */
    function allowance(address owner, address spender) external view returns (uint256);

    /**
     * @dev Sets `amount` as the allowance of `spender` over the caller's tokens.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * IMPORTANT: Beware that changing an allowance with this method brings the risk
     * that someone may use both the old and the new allowance by unfortunate
     * transaction ordering. One possible solution to mitigate this race
     * condition is to first reduce the spender's allowance to 0 and set the
     * desired value afterwards:
     * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
     *
     * Emits an {Approval} event.
     */
    function approve(address spender, uint256 amount) external returns (bool);

    /**
     * @dev Moves `amount` tokens from `sender` to `recipient` using the
     * allowance mechanism. `amount` is then deducted from the caller's
     * allowance.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * Emits a {Transfer} event.
     */
    function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);

    /**
     * @dev Emitted when `value` tokens are moved from one account (`from`) to
     * another (`to`).
     *
     * Note that `value` may be zero.
     */
    event Transfer(address indexed from, address indexed to, uint256 value);

    /**
     * @dev Emitted when the allowance of a `spender` for an `owner` is set by
     * a call to {approve}. `value` is the new allowance.
     */
    event Approval(address indexed owner, address indexed spender, uint256 value);
}

/**
 * @dev Implementation of the {IERC20} interface.
 *
 * This implementation is agnostic to the way tokens are created. This means
 * that a supply mechanism has to be added in a derived contract using {_mint}.
 * For a generic mechanism see {ERC20Mintable}.
 *
 * TIP: For a detailed writeup see our guide
 * https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How
 * to implement supply mechanisms].
 *
 * We have followed general OpenZeppelin guidelines: functions revert instead
 * of returning `false` on failure. This behavior is nonetheless conventional
 * and does not conflict with the expectations of ERC20 applications.
 *
 * Additionally, an {Approval} event is emitted on calls to {transferFrom}.
 * This allows applications to reconstruct the allowance for all accounts just
 * by listening to said events. Other implementations of the EIP may not emit
 * these events, as it isn't required by the specification.
 *
 * Finally, the non-standard {decreaseAllowance} and {increaseAllowance}
 * functions have been added to mitigate the well-known issues around setting
 * allowances. See {IERC20-approve}.
 */
contract ERC20 is IERC20 {
    using SafeMath for uint256;

    mapping (address => uint256) private _balances;

    mapping (address => mapping (address => uint256)) private _allowances;

    uint256 private _totalSupply;

    constructor(uint256 initValue) public {
        _totalSupply = initValue;
        _balances[msg.sender] = initValue;
    }

    /**
     * @dev See {IERC20-totalSupply}.
     */
    function totalSupply() public view override returns (uint256) {
        return _totalSupply;
    }

    /**
     * @dev See {IERC20-totalSupply}.
     */
    function getAddress() public view returns (address) {
        return address(this);
    }

    /**
     * @dev See {IERC20-balanceOf}.
     */
    function balanceOf(address account) public view override returns (uint256) {
        return _balances[account];
    }

    /**
     * @dev See {IERC20-transfer}.
     *
     * Requirements:
     *
     * - `recipient` cannot be the zero address.
     * - the caller must have a balance of at least `amount`.
     */
    function transfer(address recipient, uint256 amount) public virtual override returns (bool) {
        _transfer(msg.sender, recipient, amount);
        return true;
    }

    /**
     * @dev See {IERC20-allowance}.
     */
    function allowance(address owner, address spender) public view virtual override returns (uint256) {
        return _allowances[owner][spender];
    }

    /**
     * @dev See {IERC20-approve}.
     *
     * Requirements:
     *
     * - `spender` cannot be the zero address.
     */
    function approve(address spender, uint256 amount) public virtual override returns (bool) {
        _approve(msg.sender, spender, amount);
        return true;
    }

    /**
     * @dev See {IERC20-transferFrom}.
     *
     * Emits an {Approval} event indicating the updated allowance. This is not
     * required by the EIP. See the note at the beginning of {ERC20};
     *
     * Requirements:
     * - `sender` and `recipient` cannot be the zero address.
     * - `sender` must have a balance of at least `amount`.
     * - the caller must have allowance for `sender`'s tokens of at least
     * `amount`.
     */
    function transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool) {
        _transfer(sender, recipient, amount);
        _approve(sender, msg.sender, _allowances[sender][msg.sender].sub(amount, "ERC20: transfer amount exceeds allowance"));
        return true;
    }

    /**
     * @dev Atomically increases the allowance granted to `spender` by the caller.
     *
     * This is an alternative to {approve} that can be used as a mitigation for
     * problems described in {IERC20-approve}.
     *
     * Emits an {Approval} event indicating the updated allowance.
     *
     * Requirements:
     *
     * - `spender` cannot be the zero address.
     */
    function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) {
        _approve(msg.sender, spender, _allowances[msg.sender][spender].add(addedValue));
        return true;
    }

    /**
     * @dev Atomically decreases the allowance granted to `spender` by the caller.
     *
     * This is an alternative to {approve} that can be used as a mitigation for
     * problems described in {IERC20-approve}.
     *
     * Emits an {Approval} event indicating the updated allowance.
     *
     * Requirements:
     *
     * - `spender` cannot be the zero address.
     * - `spender` must have allowance for the caller of at least
     * `subtractedValue`.
     */
    function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) {
        _approve(msg.sender, spender, _allowances[msg.sender][spender].sub(subtractedValue, "ERC20: decreased allowance below zero"));
        return true;
    }

    receive() payable external {}

    /**
     * @dev Moves tokens `amount` from `sender` to `recipient`.
     *
     * This is internal function is equivalent to {transfer}, and can be used to
     * e.g. implement automatic token fees, slashing mechanisms, etc.
     *
     * Emits a {Transfer} event.
     *
     * Requirements:
     *
     * - `sender` cannot be the zero address.
     * - `recipient` cannot be the zero address.
     * - `sender` must have a balance of at least `amount`.
     */
    function _transfer(address sender, address recipient, uint256 amount) internal virtual {
        require(sender != address(0), "ERC20: transfer from the zero address");
        require(recipient != address(0), "ERC20: transfer to the zero address");

        _beforeTokenTransfer(sender, recipient, amount);

        _balances[sender] = _balances[sender].sub(amount, "ERC20: transfer amount exceeds balance");
        _balances[recipient] = _balances[recipient].add(amount);
        emit Transfer(sender, recipient, amount);
    }

    /** @dev Creates `amount` tokens and assigns them to `account`, increasing
     * the total supply.
     *
     * Emits a {Transfer} event with `from` set to the zero address.
     *
     * Requirements
     *
     * - `to` cannot be the zero address.
     */
    function _mint(address account, uint256 amount) internal virtual {
        require(account != address(0), "ERC20: mint to the zero address");

        _beforeTokenTransfer(address(0), account, amount);

        _totalSupply = _totalSupply.add(amount);
        _balances[account] = _balances[account].add(amount);
        emit Transfer(address(0), account, amount);
    }

    /**
     * @dev Destroys `amount` tokens from `account`, reducing the
     * total supply.
     *
     * Emits a {Transfer} event with `to` set to the zero address.
     *
     * Requirements
     *
     * - `account` cannot be the zero address.
     * - `account` must have at least `amount` tokens.
     */
    function _burn(address account, uint256 amount) internal virtual {
        require(account != address(0), "ERC20: burn from the zero address");

        _beforeTokenTransfer(account, address(0), amount);

        _balances[account] = _balances[account].sub(amount, "ERC20: burn amount exceeds balance");
        _totalSupply = _totalSupply.sub(amount);
        emit Transfer(account, address(0), amount);
    }

    /**
     * @dev Sets `amount` as the allowance of `spender` over the `owner`s tokens.
     *
     * This is internal function is equivalent to `approve`, and can be used to
     * e.g. set automatic allowances for certain subsystems, etc.
     *
     * Emits an {Approval} event.
     *
     * Requirements:
     *
     * - `owner` cannot be the zero address.
     * - `spender` cannot be the zero address.
     */
    function _approve(address owner, address spender, uint256 amount) internal virtual {
        require(owner != address(0), "ERC20: approve from the zero address");
        require(spender != address(0), "ERC20: approve to the zero address");

        _allowances[owner][spender] = amount;
        emit Approval(owner, spender, amount);
    }

    /**
     * @dev Destroys `amount` tokens from `account`.`amount` is then deducted
     * from the caller's allowance.
     *
     * See {_burn} and {_approve}.
     */
    function _burnFrom(address account, uint256 amount) internal virtual {
        _burn(account, amount);
        _approve(account, msg.sender, _allowances[account][msg.sender].sub(amount, "ERC20: burn amount exceeds allowance"));
    }

    /**
     * @dev Hook that is called before any transfer of tokens. This includes
     * minting and burning.
     *
     * Calling conditions:
     *
     * - when `from` and `to` are both non-zero, `amount` of `from`'s tokens
     * will be to transferred to `to`.
     * - when `from` is zero, `amount` tokens will be minted for `to`.
     * - when `to` is zero, `amount` of `from`'s tokens will be burned.
     * - `from` and `to` are never both zero.
     *
     * To learn more about hooks, head to xref:ROOT:using-hooks.adoc[Using Hooks].
     */
    function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual { }
}

/**
 * @dev Wrappers over Solidity's arithmetic operations with added overflow
 * checks.
 *
 * Arithmetic operations in Solidity wrap on overflow. This can easily result
 * in bugs, because programmers usually assume that an overflow raises an
 * error, which is the standard behavior in high level programming languages.
 * `SafeMath` restores this intuition by reverting the transaction when an
 * operation overflows.
 *
 * Using this library instead of the unchecked operations eliminates an entire
 * class of bugs, so it's recommended to use it always.
 */
library SafeMath {
    /**
     * @dev Returns the addition of two unsigned integers, reverting on
     * overflow.
     *
     * Counterpart to Solidity's `+` operator.
     *
     * Requirements:
     * - Addition cannot overflow.
     */
    function add(uint256 a, uint256 b) internal pure returns (uint256) {
        uint256 c = a + b;
        require(c >= a, "SafeMath: addition overflow");

        return c;
    }

    /**
     * @dev Returns the subtraction of two unsigned integers, reverting on
     * overflow (when the result is negative).
     *
     * Counterpart to Solidity's `-` operator.
     *
     * Requirements:
     * - Subtraction cannot overflow.
     */
    function sub(uint256 a, uint256 b) internal pure returns (uint256) {
        return sub(a, b, "SafeMath: subtraction overflow");
    }

    /**
     * @dev Returns the subtraction of two unsigned integers, reverting with custom message on
     * overflow (when the result is negative).
     *
     * Counterpart to Solidity's `-` operator.
     *
     * Requirements:
     * - Subtraction cannot overflow.
     *
     * _Available since v2.4.0._
     */
    function sub(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {
        require(b <= a, errorMessage);
        uint256 c = a - b;

        return c;
    }

    /**
     * @dev Returns the multiplication of two unsigned integers, reverting on
     * overflow.
     *
     * Counterpart to Solidity's `*` operator.
     *
     * Requirements:
     * - Multiplication cannot overflow.
     */
    function mul(uint256 a, uint256 b) internal pure returns (uint256) {
        // Gas optimization: this is cheaper than requiring 'a' not being zero, but the
        // benefit is lost if 'b' is also tested.
        // See: https://github.com/OpenZeppelin/openzeppelin-contracts/pull/522
        if (a == 0) {
            return 0;
        }

        uint256 c = a * b;
        require(c / a == b, "SafeMath: multiplication overflow");

        return c;
    }

    /**
     * @dev Returns the integer division of two unsigned integers. Reverts on
     * division by zero. The result is rounded towards zero.
     *
     * Counterpart to Solidity's `/` operator. Note: this function uses a
     * `revert` opcode (which leaves remaining gas untouched) while Solidity
     * uses an invalid opcode to revert (consuming all remaining gas).
     *
     * Requirements:
     * - The divisor cannot be zero.
     */
    function div(uint256 a, uint256 b) internal pure returns (uint256) {
        return div(a, b, "SafeMath: division by zero");
    }

    /**
     * @dev Returns the integer division of two unsigned integers. Reverts with custom message on
     * division by zero. The result is rounded towards zero.
     *
     * Counterpart to Solidity's `/` operator. Note: this function uses a
     * `revert` opcode (which leaves remaining gas untouched) while Solidity
     * uses an invalid opcode to revert (consuming all remaining gas).
     *
     * Requirements:
     * - The divisor cannot be zero.
     *
     * _Available since v2.4.0._
     */
    function div(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {
        // Solidity only automatically asserts when dividing by 0
        require(b > 0, errorMessage);
        uint256 c = a / b;
        // assert(a == b * c + a % b); // There is no case in which this doesn't hold

        return c;
    }

    /**
     * @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo),
     * Reverts when dividing by zero.
     *
     * Counterpart to Solidity's `%` operator. This function uses a `revert`
     * opcode (which leaves remaining gas untouched) while Solidity uses an
     * invalid opcode to revert (consuming all remaining gas).
     *
     * Requirements:
     * - The divisor cannot be zero.
     */
    function mod(uint256 a, uint256 b) internal pure returns (uint256) {
        return mod(a, b, "SafeMath: modulo by zero");
    }

    /**
     * @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo),
     * Reverts with custom message when dividing by zero.
     *
     * Counterpart to Solidity's `%` operator. This function uses a `revert`
     * opcode (which leaves remaining gas untouched) while Solidity uses an
     * invalid opcode to revert (consuming all remaining gas).
     *
     * Requirements:
     * - The divisor cannot be zero.
     *
     * _Available since v2.4.0._
     */
    function mod(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {
        require(b != 0, errorMessage);
        return a % b;
    }
}

@GalaIO can you please provide me with exact steps to reproduce please.
Thank you.

compile erc20.sol, and the compile TokenTransfer.sol，upload and instance in substrate, TokenTransfer contract init with erc20 contract accountId
//https://github.com/OpenZeppelin/openzeppelin-contracts

pragma solidity ^0.6.0;

/**
 * @dev Interface of the ERC20 standard as defined in the EIP. Does not include
 * the optional functions; to access them see {ERC20Detailed}.
 */
interface IERC20 {
    /**
     * @dev Returns the amount of tokens in existence.
     */
    function totalSupply() external view returns (uint256);

    /**
     * @dev Returns the amount of tokens owned by `account`.
     */
    function balanceOf(address account) external view returns (uint256);

    /**
     * @dev Moves `amount` tokens from the caller's account to `recipient`.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * Emits a {Transfer} event.
     */
    function transfer(address recipient, uint256 amount) external returns (bool);

    /**
     * @dev Returns the remaining number of tokens that `spender` will be
     * allowed to spend on behalf of `owner` through {transferFrom}. This is
     * zero by default.
     *
     * This value changes when {approve} or {transferFrom} are called.
     */
    function allowance(address owner, address spender) external view returns (uint256);

    /**
     * @dev Sets `amount` as the allowance of `spender` over the caller's tokens.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * IMPORTANT: Beware that changing an allowance with this method brings the risk
     * that someone may use both the old and the new allowance by unfortunate
     * transaction ordering. One possible solution to mitigate this race
     * condition is to first reduce the spender's allowance to 0 and set the
     * desired value afterwards:
     * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
     *
     * Emits an {Approval} event.
     */
    function approve(address spender, uint256 amount) external returns (bool);

    /**
     * @dev Moves `amount` tokens from `sender` to `recipient` using the
     * allowance mechanism. `amount` is then deducted from the caller's
     * allowance.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * Emits a {Transfer} event.
     */
    function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);

    /**
     * @dev Emitted when `value` tokens are moved from one account (`from`) to
     * another (`to`).
     *
     * Note that `value` may be zero.
     */
    event Transfer(address indexed from, address indexed to, uint256 value);

    /**
     * @dev Emitted when the allowance of a `spender` for an `owner` is set by
     * a call to {approve}. `value` is the new allowance.
     */
    event Approval(address indexed owner, address indexed spender, uint256 value);
}

/**
 * @dev Implementation of the {IERC20} interface.
 *
 * This implementation is agnostic to the way tokens are created. This means
 * that a supply mechanism has to be added in a derived contract using {_mint}.
 * For a generic mechanism see {ERC20Mintable}.
 *
 * TIP: For a detailed writeup see our guide
 * https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How
 * to implement supply mechanisms].
 *
 * We have followed general OpenZeppelin guidelines: functions revert instead
 * of returning `false` on failure. This behavior is nonetheless conventional
 * and does not conflict with the expectations of ERC20 applications.
 *
 * Additionally, an {Approval} event is emitted on calls to {transferFrom}.
 * This allows applications to reconstruct the allowance for all accounts just
 * by listening to said events. Other implementations of the EIP may not emit
 * these events, as it isn't required by the specification.
 *
 * Finally, the non-standard {decreaseAllowance} and {increaseAllowance}
 * functions have been added to mitigate the well-known issues around setting
 * allowances. See {IERC20-approve}.
 */
contract ERC20 is IERC20 {
    using SafeMath for uint256;

    mapping (address => uint256) private _balances;

    mapping (address => mapping (address => uint256)) private _allowances;

    uint256 private _totalSupply;

    constructor(uint256 initValue) public {
        _totalSupply = initValue;
        _balances[msg.sender] = initValue;
    }

    /**
     * @dev See {IERC20-totalSupply}.
     */
    function totalSupply() public view override returns (uint256) {
        return _totalSupply;
    }

    /**
     * @dev See {IERC20-totalSupply}.
     */
    function getAddress() public view returns (address) {
        return address(this);
    }

    /**
     * @dev See {IERC20-balanceOf}.
     */
    function balanceOf(address account) public view override returns (uint256) {
        return _balances[account];
    }

    /**
     * @dev See {IERC20-transfer}.
     *
     * Requirements:
     *
     * - `recipient` cannot be the zero address.
     * - the caller must have a balance of at least `amount`.
     */
    function transfer(address recipient, uint256 amount) public virtual override returns (bool) {
        _transfer(msg.sender, recipient, amount);
        return true;
    }

    /**
     * @dev See {IERC20-allowance}.
     */
    function allowance(address owner, address spender) public view virtual override returns (uint256) {
        return _allowances[owner][spender];
    }

    /**
     * @dev See {IERC20-approve}.
     *
     * Requirements:
     *
     * - `spender` cannot be the zero address.
     */
    function approve(address spender, uint256 amount) public virtual override returns (bool) {
        _approve(msg.sender, spender, amount);
        return true;
    }

    /**
     * @dev See {IERC20-transferFrom}.
     *
     * Emits an {Approval} event indicating the updated allowance. This is not
     * required by the EIP. See the note at the beginning of {ERC20};
     *
     * Requirements:
     * - `sender` and `recipient` cannot be the zero address.
     * - `sender` must have a balance of at least `amount`.
     * - the caller must have allowance for `sender`'s tokens of at least
     * `amount`.
     */
    function transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool) {
        _transfer(sender, recipient, amount);
        _approve(sender, msg.sender, _allowances[sender][msg.sender].sub(amount, "ERC20: transfer amount exceeds allowance"));
        return true;
    }

    /**
     * @dev Atomically increases the allowance granted to `spender` by the caller.
     *
     * This is an alternative to {approve} that can be used as a mitigation for
     * problems described in {IERC20-approve}.
     *
     * Emits an {Approval} event indicating the updated allowance.
     *
     * Requirements:
     *
     * - `spender` cannot be the zero address.
     */
    function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) {
        _approve(msg.sender, spender, _allowances[msg.sender][spender].add(addedValue));
        return true;
    }

    /**
     * @dev Atomically decreases the allowance granted to `spender` by the caller.
     *
     * This is an alternative to {approve} that can be used as a mitigation for
     * problems described in {IERC20-approve}.
     *
     * Emits an {Approval} event indicating the updated allowance.
     *
     * Requirements:
     *
     * - `spender` cannot be the zero address.
     * - `spender` must have allowance for the caller of at least
     * `subtractedValue`.
     */
    function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) {
        _approve(msg.sender, spender, _allowances[msg.sender][spender].sub(subtractedValue, "ERC20: decreased allowance below zero"));
        return true;
    }

    receive() payable external {}

    /**
     * @dev Moves tokens `amount` from `sender` to `recipient`.
     *
     * This is internal function is equivalent to {transfer}, and can be used to
     * e.g. implement automatic token fees, slashing mechanisms, etc.
     *
     * Emits a {Transfer} event.
     *
     * Requirements:
     *
     * - `sender` cannot be the zero address.
     * - `recipient` cannot be the zero address.
     * - `sender` must have a balance of at least `amount`.
     */
    function _transfer(address sender, address recipient, uint256 amount) internal virtual {
        require(sender != address(0), "ERC20: transfer from the zero address");
        require(recipient != address(0), "ERC20: transfer to the zero address");

        _beforeTokenTransfer(sender, recipient, amount);

        _balances[sender] = _balances[sender].sub(amount, "ERC20: transfer amount exceeds balance");
        _balances[recipient] = _balances[recipient].add(amount);
        emit Transfer(sender, recipient, amount);
    }

    /** @dev Creates `amount` tokens and assigns them to `account`, increasing
     * the total supply.
     *
     * Emits a {Transfer} event with `from` set to the zero address.
     *
     * Requirements
     *
     * - `to` cannot be the zero address.
     */
    function _mint(address account, uint256 amount) internal virtual {
        require(account != address(0), "ERC20: mint to the zero address");

        _beforeTokenTransfer(address(0), account, amount);

        _totalSupply = _totalSupply.add(amount);
        _balances[account] = _balances[account].add(amount);
        emit Transfer(address(0), account, amount);
    }

    /**
     * @dev Destroys `amount` tokens from `account`, reducing the
     * total supply.
     *
     * Emits a {Transfer} event with `to` set to the zero address.
     *
     * Requirements
     *
     * - `account` cannot be the zero address.
     * - `account` must have at least `amount` tokens.
     */
    function _burn(address account, uint256 amount) internal virtual {
        require(account != address(0), "ERC20: burn from the zero address");

        _beforeTokenTransfer(account, address(0), amount);

        _balances[account] = _balances[account].sub(amount, "ERC20: burn amount exceeds balance");
        _totalSupply = _totalSupply.sub(amount);
        emit Transfer(account, address(0), amount);
    }

    /**
     * @dev Sets `amount` as the allowance of `spender` over the `owner`s tokens.
     *
     * This is internal function is equivalent to `approve`, and can be used to
     * e.g. set automatic allowances for certain subsystems, etc.
     *
     * Emits an {Approval} event.
     *
     * Requirements:
     *
     * - `owner` cannot be the zero address.
     * - `spender` cannot be the zero address.
     */
    function _approve(address owner, address spender, uint256 amount) internal virtual {
        require(owner != address(0), "ERC20: approve from the zero address");
        require(spender != address(0), "ERC20: approve to the zero address");

        _allowances[owner][spender] = amount;
        emit Approval(owner, spender, amount);
    }

    /**
     * @dev Destroys `amount` tokens from `account`.`amount` is then deducted
     * from the caller's allowance.
     *
     * See {_burn} and {_approve}.
     */
    function _burnFrom(address account, uint256 amount) internal virtual {
        _burn(account, amount);
        _approve(account, msg.sender, _allowances[account][msg.sender].sub(amount, "ERC20: burn amount exceeds allowance"));
    }

    /**
     * @dev Hook that is called before any transfer of tokens. This includes
     * minting and burning.
     *
     * Calling conditions:
     *
     * - when `from` and `to` are both non-zero, `amount` of `from`'s tokens
     * will be to transferred to `to`.
     * - when `from` is zero, `amount` tokens will be minted for `to`.
     * - when `to` is zero, `amount` of `from`'s tokens will be burned.
     * - `from` and `to` are never both zero.
     *
     * To learn more about hooks, head to xref:ROOT:using-hooks.adoc[Using Hooks].
     */
    function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual { }
}

/**
 * @dev Wrappers over Solidity's arithmetic operations with added overflow
 * checks.
 *
 * Arithmetic operations in Solidity wrap on overflow. This can easily result
 * in bugs, because programmers usually assume that an overflow raises an
 * error, which is the standard behavior in high level programming languages.
 * `SafeMath` restores this intuition by reverting the transaction when an
 * operation overflows.
 *
 * Using this library instead of the unchecked operations eliminates an entire
 * class of bugs, so it's recommended to use it always.
 */
library SafeMath {
    /**
     * @dev Returns the addition of two unsigned integers, reverting on
     * overflow.
     *
     * Counterpart to Solidity's `+` operator.
     *
     * Requirements:
     * - Addition cannot overflow.
     */
    function add(uint256 a, uint256 b) internal pure returns (uint256) {
        uint256 c = a + b;
        require(c >= a, "SafeMath: addition overflow");

        return c;
    }

    /**
     * @dev Returns the subtraction of two unsigned integers, reverting on
     * overflow (when the result is negative).
     *
     * Counterpart to Solidity's `-` operator.
     *
     * Requirements:
     * - Subtraction cannot overflow.
     */
    function sub(uint256 a, uint256 b) internal pure returns (uint256) {
        return sub(a, b, "SafeMath: subtraction overflow");
    }

    /**
     * @dev Returns the subtraction of two unsigned integers, reverting with custom message on
     * overflow (when the result is negative).
     *
     * Counterpart to Solidity's `-` operator.
     *
     * Requirements:
     * - Subtraction cannot overflow.
     *
     * _Available since v2.4.0._
     */
    function sub(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {
        require(b <= a, errorMessage);
        uint256 c = a - b;

        return c;
    }

    /**
     * @dev Returns the multiplication of two unsigned integers, reverting on
     * overflow.
     *
     * Counterpart to Solidity's `*` operator.
     *
     * Requirements:
     * - Multiplication cannot overflow.
     */
    function mul(uint256 a, uint256 b) internal pure returns (uint256) {
        // Gas optimization: this is cheaper than requiring 'a' not being zero, but the
        // benefit is lost if 'b' is also tested.
        // See: https://github.com/OpenZeppelin/openzeppelin-contracts/pull/522
        if (a == 0) {
            return 0;
        }

        uint256 c = a * b;
        require(c / a == b, "SafeMath: multiplication overflow");

        return c;
    }

    /**
     * @dev Returns the integer division of two unsigned integers. Reverts on
     * division by zero. The result is rounded towards zero.
     *
     * Counterpart to Solidity's `/` operator. Note: this function uses a
     * `revert` opcode (which leaves remaining gas untouched) while Solidity
     * uses an invalid opcode to revert (consuming all remaining gas).
     *
     * Requirements:
     * - The divisor cannot be zero.
     */
    function div(uint256 a, uint256 b) internal pure returns (uint256) {
        return div(a, b, "SafeMath: division by zero");
    }

    /**
     * @dev Returns the integer division of two unsigned integers. Reverts with custom message on
     * division by zero. The result is rounded towards zero.
     *
     * Counterpart to Solidity's `/` operator. Note: this function uses a
     * `revert` opcode (which leaves remaining gas untouched) while Solidity
     * uses an invalid opcode to revert (consuming all remaining gas).
     *
     * Requirements:
     * - The divisor cannot be zero.
     *
     * _Available since v2.4.0._
     */
    function div(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {
        // Solidity only automatically asserts when dividing by 0
        require(b > 0, errorMessage);
        uint256 c = a / b;
        // assert(a == b * c + a % b); // There is no case in which this doesn't hold

        return c;
    }

    /**
     * @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo),
     * Reverts when dividing by zero.
     *
     * Counterpart to Solidity's `%` operator. This function uses a `revert`
     * opcode (which leaves remaining gas untouched) while Solidity uses an
     * invalid opcode to revert (consuming all remaining gas).
     *
     * Requirements:
     * - The divisor cannot be zero.
     */
    function mod(uint256 a, uint256 b) internal pure returns (uint256) {
        return mod(a, b, "SafeMath: modulo by zero");
    }

    /**
     * @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo),
     * Reverts with custom message when dividing by zero.
     *
     * Counterpart to Solidity's `%` operator. This function uses a `revert`
     * opcode (which leaves remaining gas untouched) while Solidity uses an
     * invalid opcode to revert (consuming all remaining gas).
     *
     * Requirements:
     * - The divisor cannot be zero.
     *
     * _Available since v2.4.0._
     */
    function mod(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {
        require(b != 0, errorMessage);
        return a % b;
    }
}

@GalaIO this contract compiles fine. What issue are you seeing when you try go upload the contract to substrate?

authors: GalaIO seanyoung

repo: hyperledger-labs/solang


text:
Provide nightly builds for ACA-Py

For developers that require access to bug fixes, we should provide nightly builds (or build on merge to main?) of the ACA-Py images.
Investigate if we can leverage a nightly build in AATH or other testing situations.

@gavinok

Nightly builds would be sufficient.  Building on merge to main would cause unnecessary strain on Hyperledger's GitHub actions runner time allotments.
The nightly builds should incorporate the nightly test runs and only build/publish on success.  The workflow should only run if there are changes to the repo since the previous run, there is no point in wasting precious runner time.
The workflows you want to look at are:

https://github.com/hyperledger/aries-cloudagent-python/blob/main/.github/workflows/nightly-tests.yml

https://github.com/hyperledger/aries-cloudagent-python/blob/main/.github/workflows/publish.yml

To publish a nightly version of the image.  You'll need to update the workflow to tag the image appropriately; e.g. nightly.

https://github.com/hyperledger/aries-cloudagent-python/blob/main/.github/workflows/pythonpublish.yml

To publish a nightly python package, if we decide to do that.  This requires some additional thought and investigation due to the fact we'd be publishing more frequently to PyPi and may need to perform cleanup.

Ignore https://github.com/hyperledger/aries-cloudagent-python/blob/main/.github/workflows/publish-indy.yml, because we're dropping support for the indy-sdk releases and this workflow will go away.

source: gharchive/issue

authors: WadeBarnes swcurran usingtechnology

repo: hyperledger/aries-cloudagent-python

license_type: permissive

license_source: github-api


text:
not having a body is OK to send bound offer

Fix https://github.com/hyperledger/aries-cloudagent-python/issues/1114

weird: will resubmit

source: gharchive/pull-request


text:
Api security

Adds 2 new cli parameters:
--admin-insecure-mode
--admin-api-key
Exactly one of these two parameters are required if --admin is passed.
If an API key is provided, then requests must pass the key in the HTTP header X-API-Key otherwise the request will fail with a 401 response.

Codecov Report

Merging #67 into master will decrease coverage by 0.09%.
The diff coverage is 48.14%.

@@            Coverage Diff            @@
##           master      #67     +/-   ##
=========================================
- Coverage   70.67%   70.58%   -0.1%
=========================================
  Files         176      177      +1
  Lines        7400     7424     +24
=========================================
+ Hits         5230     5240     +10
- Misses       2170     2184     +14

authors: codecov-io nrempel


text:
Theming

remove emotion library
revert styles accordingly
extend globalStyles file as needed

Why do you want to remove the emotion library, I thought they were just added? I don't have a specific preference myself, but just curious why we're reverting

As per todays Bifold UG/WG call we're closing stale issues. Please re-open if you feel strongly its still an issue and relevent.

authors: NeilSMyers TimoGlastra jleach


text:
Error during fresh sync with parallel processing

Description
Fresh sync on Ethereum mainnet with Besu 24.7.1 and --receipt-compaction-enabled=true --Xbonsai-parallel-tx-processing-enabled=true shows an error:
execution-1  | 2024-08-02 20:23:30.946+00:00 | EthScheduler-Services-3 (batchPersistAccountData) | INFO  | SnapSyncMetricsManager | Worldstate download progress: 3.00%, Peer count: 7
execution-1  | 2024-08-02 20:24:00.240+00:00 | EthScheduler-Services-37 (importBlock) | INFO  | ImportBlocksStep | Block import progress: 378539 of 20443107 (1%), Peer count: 9
execution-1  | 2024-08-02 20:25:34.992+00:00 | vert.x-worker-thread-4 | ERROR | BaseJsonRpcProcessor | Error processing method: eth_gasPrice null
execution-1  | java.lang.IllegalStateException: Could not retrieve block #390035
execution-1  | 	at org.hyperledger.besu.ethereum.api.query.BlockchainQueries.lambda$gasPrice$25(BlockchainQueries.java:994)
execution-1  | 	at java.base/java.util.Optional.orElseThrow(Optional.java:403)
execution-1  | 	at org.hyperledger.besu.ethereum.api.query.BlockchainQueries.lambda$gasPrice$26(BlockchainQueries.java:993)
execution-1  | 	at java.base/java.util.stream.LongPipeline$1$1.accept(LongPipeline.java:177)
execution-1  | 	at java.base/java.util.stream.Streams$RangeLongSpliterator.forEachRemaining(Streams.java:232)
execution-1  | 	at java.base/java.util.Spliterator$OfLong.forEachRemaining(Spliterator.java:777)
execution-1  | 	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
execution-1  | 	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
execution-1  | 	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575)
execution-1  | 	at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
execution-1  | 	at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616)
execution-1  | 	at org.hyperledger.besu.ethereum.api.query.BlockchainQueries.gasPrice(BlockchainQueries.java:999)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.internal.methods.EthGasPrice.calculateGasPrice(EthGasPrice.java:49)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.internal.methods.EthGasPrice.response(EthGasPrice.java:45)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.execution.BaseJsonRpcProcessor.process(BaseJsonRpcProcessor.java:44)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.execution.TracedJsonRpcProcessor.process(TracedJsonRpcProcessor.java:54)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.execution.TimedJsonRpcProcessor.process(TimedJsonRpcProcessor.java:45)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.execution.JsonRpcExecutor.execute(JsonRpcExecutor.java:92)
execution-1  | 	at org.hyperledger.besu.ethereum.api.handlers.AbstractJsonRpcExecutor.executeRequest(AbstractJsonRpcExecutor.java:87)
execution-1  | 	at org.hyperledger.besu.ethereum.api.handlers.JsonRpcObjectExecutor.execute(JsonRpcObjectExecutor.java:57)
execution-1  | 	at org.hyperledger.besu.ethereum.api.handlers.JsonRpcExecutorHandler.lambda$handler$0(JsonRpcExecutorHandler.java:57)
execution-1  | 	at java.base/java.util.Optional.ifPresentOrElse(Optional.java:196)
execution-1  | 	at org.hyperledger.besu.ethereum.api.handlers.JsonRpcExecutorHandler.lambda$handler$2(JsonRpcExecutorHandler.java:54)
execution-1  | 	at io.vertx.ext.web.impl.BlockingHandlerDecorator.lambda$handle$0(BlockingHandlerDecorator.java:48)
execution-1  | 	at io.vertx.core.impl.ContextImpl.lambda$executeBlocking$1(ContextImpl.java:191)
execution-1  | 	at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:279)
execution-1  | 	at io.vertx.core.impl.ContextImpl.lambda$internalExecuteBlocking$2(ContextImpl.java:210)
execution-1  | 	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
execution-1  | 	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
execution-1  | 	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
execution-1  | 	at java.base/java.lang.Thread.run(Thread.java:1583)
execution-1  | 2024-08-02 20:25:38.168+00:00 | EthScheduler-Services-3 (batchPersistAccountData) | INFO  | SnapSyncMetricsManager | Worldstate download progress: 3.49%, Peer count: 10

Steps to Reproduce (Bug)
SNAP sync Ethereum mainnet with --Xbonsai-parallel-tx-processing-enabled=true. Syncing without this parameter gets past the problematic block without error messages.
Versions (Add all that apply)

Software version: 24.7.1
OS Name & Version: Debian 12
Docker Version: 27.1.1

Same on Holesky:
execution-1  | 2024-08-02 20:44:18.986+00:00 | vert.x-worker-thread-13 | ERROR | BaseJsonRpcProcessor | Error processing method: eth_gasPrice null
execution-1  | java.lang.IllegalStateException: Could not retrieve block #903907
execution-1  | 	at org.hyperledger.besu.ethereum.api.query.BlockchainQueries.lambda$gasPrice$25(BlockchainQueries.java:994)
execution-1  | 	at java.base/java.util.Optional.orElseThrow(Optional.java:403)
execution-1  | 	at org.hyperledger.besu.ethereum.api.query.BlockchainQueries.lambda$gasPrice$26(BlockchainQueries.java:993)
execution-1  | 	at java.base/java.util.stream.LongPipeline$1$1.accept(LongPipeline.java:177)
execution-1  | 	at java.base/java.util.stream.Streams$RangeLongSpliterator.forEachRemaining(Streams.java:232)
execution-1  | 	at java.base/java.util.Spliterator$OfLong.forEachRemaining(Spliterator.java:777)
execution-1  | 	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
execution-1  | 	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
execution-1  | 	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575)
execution-1  | 	at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
execution-1  | 	at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616)
execution-1  | 	at org.hyperledger.besu.ethereum.api.query.BlockchainQueries.gasPrice(BlockchainQueries.java:999)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.internal.methods.EthGasPrice.calculateGasPrice(EthGasPrice.java:49)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.internal.methods.EthGasPrice.response(EthGasPrice.java:45)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.execution.BaseJsonRpcProcessor.process(BaseJsonRpcProcessor.java:44)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.execution.TracedJsonRpcProcessor.process(TracedJsonRpcProcessor.java:54)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.execution.TimedJsonRpcProcessor.process(TimedJsonRpcProcessor.java:45)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.execution.JsonRpcExecutor.execute(JsonRpcExecutor.java:92)
execution-1  | 	at org.hyperledger.besu.ethereum.api.handlers.AbstractJsonRpcExecutor.executeRequest(AbstractJsonRpcExecutor.java:87)
execution-1  | 	at org.hyperledger.besu.ethereum.api.handlers.JsonRpcObjectExecutor.execute(JsonRpcObjectExecutor.java:57)
execution-1  | 	at org.hyperledger.besu.ethereum.api.handlers.JsonRpcExecutorHandler.lambda$handler$0(JsonRpcExecutorHandler.java:57)
execution-1  | 	at java.base/java.util.Optional.ifPresentOrElse(Optional.java:196)
execution-1  | 	at org.hyperledger.besu.ethereum.api.handlers.JsonRpcExecutorHandler.lambda$handler$2(JsonRpcExecutorHandler.java:54)
execution-1  | 	at io.vertx.ext.web.impl.BlockingHandlerDecorator.lambda$handle$0(BlockingHandlerDecorator.java:48)
execution-1  | 	at io.vertx.core.impl.ContextImpl.lambda$executeBlocking$1(ContextImpl.java:191)
execution-1  | 	at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:279)
execution-1  | 	at io.vertx.core.impl.ContextImpl.lambda$internalExecuteBlocking$2(ContextImpl.java:210)
execution-1  | 	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
execution-1  | 	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
execution-1  | 	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
execution-1  | 	at java.base/java.lang.Thread.run(Thread.java:1583)

Full parameters:
--data-path /var/lib/besu --p2p-port 30303 --rpc-http-enabled --rpc-http-host 0.0.0.0 --rpc-http-port 8545 --rpc-http-cors-origins=* --rpc-http-max-active-connections=65536 --rpc-max-logs-range=65536 --rpc-ws-enabled --rpc-ws-host 0.0.0.0 --rpc-ws-port 8546 --max-peers 25 --host-allowlist=* --engine-host-allowlist=* --engine-jwt-secret=/var/lib/besu/ee-secret/jwtsecret --engine-rpc-port=8551 --logging info --metrics-enabled --metrics-host 0.0.0.0 --metrics-port 6060 --nat-method=DOCKER --network holesky --rpc-http-api WEB3,ETH,NET --data-storage-format=BONSAI --sync-mode=SNAP --receipt-compaction-enabled=true --Xbonsai-parallel-tx-processing-enabled=true

Without parallel processing on Ethereum mainnet, this still happens:
execution-1  | 2024-08-02 20:53:50.832+00:00 | vert.x-worker-thread-12 | ERROR | BaseJsonRpcProcessor | Error processing method: eth_gasPrice null
execution-1  | java.lang.IllegalStateException: Could not retrieve block #986679
execution-1  | 	at org.hyperledger.besu.ethereum.api.query.BlockchainQueries.lambda$gasPrice$25(BlockchainQueries.java:994)
execution-1  | 	at java.base/java.util.Optional.orElseThrow(Optional.java:403)
execution-1  | 	at org.hyperledger.besu.ethereum.api.query.BlockchainQueries.lambda$gasPrice$26(BlockchainQueries.java:993)
execution-1  | 	at java.base/java.util.stream.LongPipeline$1$1.accept(LongPipeline.java:177)
execution-1  | 	at java.base/java.util.stream.Streams$RangeLongSpliterator.forEachRemaining(Streams.java:232)
execution-1  | 	at java.base/java.util.Spliterator$OfLong.forEachRemaining(Spliterator.java:777)
execution-1  | 	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
execution-1  | 	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
execution-1  | 	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575)
execution-1  | 	at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
execution-1  | 	at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616)
execution-1  | 	at org.hyperledger.besu.ethereum.api.query.BlockchainQueries.gasPrice(BlockchainQueries.java:999)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.internal.methods.EthGasPrice.calculateGasPrice(EthGasPrice.java:49)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.internal.methods.EthGasPrice.response(EthGasPrice.java:45)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.execution.BaseJsonRpcProcessor.process(BaseJsonRpcProcessor.java:44)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.execution.TracedJsonRpcProcessor.process(TracedJsonRpcProcessor.java:54)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.execution.TimedJsonRpcProcessor.process(TimedJsonRpcProcessor.java:45)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.execution.JsonRpcExecutor.execute(JsonRpcExecutor.java:92)
execution-1  | 	at org.hyperledger.besu.ethereum.api.handlers.AbstractJsonRpcExecutor.executeRequest(AbstractJsonRpcExecutor.java:87)
execution-1  | 	at org.hyperledger.besu.ethereum.api.handlers.JsonRpcObjectExecutor.execute(JsonRpcObjectExecutor.java:57)
execution-1  | 	at org.hyperledger.besu.ethereum.api.handlers.JsonRpcExecutorHandler.lambda$handler$0(JsonRpcExecutorHandler.java:57)
execution-1  | 	at java.base/java.util.Optional.ifPresentOrElse(Optional.java:196)
execution-1  | 	at org.hyperledger.besu.ethereum.api.handlers.JsonRpcExecutorHandler.lambda$handler$2(JsonRpcExecutorHandler.java:54)
execution-1  | 	at io.vertx.ext.web.impl.BlockingHandlerDecorator.lambda$handle$0(BlockingHandlerDecorator.java:48)
execution-1  | 	at io.vertx.core.impl.ContextImpl.lambda$executeBlocking$1(ContextImpl.java:191)
execution-1  | 	at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:279)
execution-1  | 	at io.vertx.core.impl.ContextImpl.lambda$internalExecuteBlocking$2(ContextImpl.java:210)
execution-1  | 	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
execution-1  | 	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
execution-1  | 	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
execution-1  | 	at java.base/java.lang.Thread.run(Thread.java:1583)

Just later in the sync process

Vanilla, neither parallel processing nor receipts compaction, I still see this error - just a lot less frequently
execution-1  | 2024-08-02 21:24:36.669+00:00 | vert.x-worker-thread-0 | ERROR | BaseJsonRpcProcessor | Error processing method: eth_gasPrice null
execution-1  | java.lang.IllegalStateException: Could not retrieve block #695838
execution-1  | 	at org.hyperledger.besu.ethereum.api.query.BlockchainQueries.lambda$gasPrice$25(BlockchainQueries.java:994)
execution-1  | 	at java.base/java.util.Optional.orElseThrow(Optional.java:403)
execution-1  | 	at org.hyperledger.besu.ethereum.api.query.BlockchainQueries.lambda$gasPrice$26(BlockchainQueries.java:993)
execution-1  | 	at java.base/java.util.stream.LongPipeline$1$1.accept(LongPipeline.java:177)
execution-1  | 	at java.base/java.util.stream.Streams$RangeLongSpliterator.forEachRemaining(Streams.java:232)
execution-1  | 	at java.base/java.util.Spliterator$OfLong.forEachRemaining(Spliterator.java:777)
execution-1  | 	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
execution-1  | 	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
execution-1  | 	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575)
execution-1  | 	at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
execution-1  | 	at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616)
execution-1  | 	at org.hyperledger.besu.ethereum.api.query.BlockchainQueries.gasPrice(BlockchainQueries.java:999)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.internal.methods.EthGasPrice.calculateGasPrice(EthGasPrice.java:49)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.internal.methods.EthGasPrice.response(EthGasPrice.java:45)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.execution.BaseJsonRpcProcessor.process(BaseJsonRpcProcessor.java:44)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.execution.TracedJsonRpcProcessor.process(TracedJsonRpcProcessor.java:54)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.execution.TimedJsonRpcProcessor.process(TimedJsonRpcProcessor.java:45)
execution-1  | 	at org.hyperledger.besu.ethereum.api.jsonrpc.execution.JsonRpcExecutor.execute(JsonRpcExecutor.java:92)
execution-1  | 	at org.hyperledger.besu.ethereum.api.handlers.AbstractJsonRpcExecutor.executeRequest(AbstractJsonRpcExecutor.java:87)
execution-1  | 	at org.hyperledger.besu.ethereum.api.handlers.JsonRpcObjectExecutor.execute(JsonRpcObjectExecutor.java:57)
execution-1  | 	at org.hyperledger.besu.ethereum.api.handlers.JsonRpcExecutorHandler.lambda$handler$0(JsonRpcExecutorHandler.java:57)
execution-1  | 	at java.base/java.util.Optional.ifPresentOrElse(Optional.java:196)
execution-1  | 	at org.hyperledger.besu.ethereum.api.handlers.JsonRpcExecutorHandler.lambda$handler$2(JsonRpcExecutorHandler.java:54)
execution-1  | 	at io.vertx.ext.web.impl.BlockingHandlerDecorator.lambda$handle$0(BlockingHandlerDecorator.java:48)
execution-1  | 	at io.vertx.core.impl.ContextImpl.lambda$executeBlocking$1(ContextImpl.java:191)
execution-1  | 	at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:279)
execution-1  | 	at io.vertx.core.impl.ContextImpl.lambda$internalExecuteBlocking$2(ContextImpl.java:210)
execution-1  | 	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
execution-1  | 	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
execution-1  | 	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
execution-1  | 	at java.base/java.lang.Thread.run(Thread.java:1583)

Sorry, confused. Duplicate of which issue? This seems to say it duplicates itself 😅

sorry, linked the correct issue now

repo: hyperledger/besu


text:
Fix get logs patch 2

Signed-off-by: Karim TAAM karim.t2am@gmail.com

PR description
LogBloom could be invalid in the cache after a reorg. With this PR, there is an update of the cache every time a reorg takes place
Test performed

Sync on goerli (reorg etc.)

Changelog

[ ] I thought about the changelog and included a changelog update if required.

LGTM. I'd strongly recommend updating the cache version again though - those who skip release to release still only reindex once, but anyone who updated to the snapshot reindexes again to fix the log cache. So helps some people with no down side.

ok you convinced me I will update the version


text:
Alternative proposal for breaking change to the way plugins load cli options

https://wiki.hyperledger.org/display/BESU/DRAFT+-+Pico+CLI+Plugin+Integration
The main change is to move preparePlugins into the begging of the run method. This means that all the cli parsing will happen before the method register is called.
The only way to register cli options is to use the extra hook provided by BesuPlugins::registerPicoCLIOptions

Is this still active or can it be closed? We would like to clean up old outstanding PRs.

Related to https://wiki.hyperledger.org/display/BESU/DRAFT+-+Pico+CLI+Plugin+Integration and https://github.com/hyperledger/besu/pull/2768
Maybe useful if someone looks at plugins again.

authors: antonydenyer jflo


text:
test(weaver/sdk/node): fix flake - InteroperableHelper cryptographic fn

Description

On an unrelated PR (e.g. it didn't change anything related to this job) the unit_test_weaver_node_sdk_local job failed.
I re-executed it and then it worked fine.

Full Error Logs
2024-06-19T13-16-15-weaver-flaky-unit-tests.log
Error Logs Snippet
2024-06-19T13:17:30.4147489Z   52 passing (11s)
2024-06-19T13:17:30.4148156Z   1 failing
2024-06-19T13:17:30.4148459Z
2024-06-19T13:17:30.4151570Z   1) InteroperableHelper
2024-06-19T13:17:30.4152456Z        cryptographic functions
2024-06-19T13:17:30.4153640Z          encrypt and decrypt a message with default 128-bit AES key:
2024-06-19T13:17:30.4155558Z      AssertionError: expected [Function] to not throw an error but 'AssertionError: expected [Function] t…' was thrown
2024-06-19T13:17:30.4159424Z       at Context.<anonymous> (test/InteroperableHelper.js:154:22)
2024-06-19T13:17:30.4160622Z       at processImmediate (node:internal/timers:476:21)
2024-06-19T13:17:30.4161562Z

Acceptance Criteria

Test is consistently passing.

cc: @VRamakrishna @sandeepnRES

Is this task still open?

@Dozie2001 Yes. The caveat: We don't know how to reproduce this.

repo: hyperledger/cacti


text:
docs(examples): supply chain app WWW root config

Description
The supply chain app example configures its API server at the moment with a WWW path for the front-end that is hardcoded in the back-end package. This makes it inflexible and in certain situations will just break the example because the back-end will not serve the UI if the path is incorrect.
We need to have a way of passing in a CLI/ENV arg/variable with the WWW root path so that this can be remedied by the users regardless of how they choose to install/try out the example.
Acceptance Criteria

The example back-end can serve the front-end assets regardless of what is the current working directory where it was started from.

cc: @sfuji822 @jonathan-m-hamilton @takeutak

Update: this issue was made much lower priority since we containerized the entire example supply chain app so that this bug no longer happens as long as you are using the provided container image.
It is still an issue if you want to build locally which is what people who actually want to contribute will have to do sooner or later so the bug still needs to be addressed, just not as urgently.

Working on this.

authors: jordigiam petermetz

repo: hyperledger/cactus


text:
"Missing 'proposalResponses' parameter in transaction request"

I recently started learning fabric and wrote a small demo, but there were errors when uploading data using postman. When I upload the following data, the code will not make mistakes.But when the data I upload is 15M, an error will be reported,"Missing 'proposalResponses' parameter in transaction request"。here is the data
{
    "identifier": "client0_to_rsu4_epoch1",
    "data": {
        "enc_vectors": {
            "conv1.weight": "conv1.weightxxxxxxxxxxx",
            "conv1.bias": "conv1.biasxxxxx",
            "conv2.weight": "conv2.weightxxx",
            "conv2.bias": "conv2.biasxxxxxx",
            "fc1.weight": "fc1.weightxxxxx",
            "fc1.bias": "fc1.biasxxxx",
            "fc2.weight": "fc2.weightxxxxxxx",
            "fc2.bias": "fc2.biasxxxx"
        },
        "dec_aes_key": "chBXLZA03PXYzs43UArhGfGsSn7TACdldFIqYPTO3/FjS73h50IX4RSoALE13fqkROEray0lsLiShIN/48exerGDEaL0BN6O0gGpq55WwNtRUqrsOvGzwisFLJVGK3d5nCyo+Hw8QwjO4fwfQs2ynpeubP1+Zr/TIx09p4NDUHM=",
        "loss_slice": 0.10846090443590854
    }
}

The following is the data displayed in the docker log
docker logs dev-peer1.org1.example.com-privacy_cc-1.0
invoke is runningadd
进入add函数
反序列化中
根据Id获取值
添加数据
序列化数据
保存数据
发送事件

I wonder if this problem occurs because the uploaded data is too large.
I tried to change PreferredMaxBytes from 512KB to 15MB, but it didn't work.
Is there any way for me to upload such large data?

i also have this problem , if any one can help me? thanks

when i try to send a more large args, it have this issue

@JessKXWL  Dear friends, how did you deal this problem later?

@JessKXWL Dear friends, how did you deal this problem later?

I didn't solve this problem, but later I tried to find out the limit. It's OK to upload data below 4M. The maximum data transmitted by the gossip protocol is also 4M, so I think it's related to the gossip protocol. However, there will still be errors when modifying the maximum data transmitted by the gossip protocol. It may be that I changed the wrong place

@JessKXWL ,thank you very much! i will try to have a look on it , this problem is really Strange

@JessKXWL : Check the network.json, verify the peer endpoints configured are correct or not.

我的问题跟你的问题一样。但我是获取数据时报的这个错误。

时间太久了，我有点不太记得了，我印象中是因为grpc协议传输的数据设置为了4M，而我传输的数据远超过4M，所以出错了。在这个代码里面有地方可以设置GRPC协议传输数据大小，不过我当时设置的时候可能没找对地方，没设置成功。
------------------ 原始邮件 ------------------
发件人:                                                                                "hyperledger/fabric-sdk-py"                                                                                @.>;
发送时间: 2023年11月27日(星期一) 晚上6:51
@.>;
@.@.>;
主题: Re: [hyperledger/fabric-sdk-py] "Missing 'proposalResponses' parameter in transaction request" (Issue #162)
我的问题跟你的问题一样。但我是获取数据时报的这个错误。
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

确实是这样，是由于grpc协议数据量的关系，貌似是在一个配置文件里修改，数额修改地大些，也别太大
------------------ 原始邮件 ------------------
发件人:                                                                                "hyperledger/fabric-sdk-py"                                                                                @.>;
发送时间: 2023年11月27日(星期一) 晚上11:04
@.>;
@.@.>;
主题: Re: [hyperledger/fabric-sdk-py] "Missing 'proposalResponses' parameter in transaction request" (Issue #162)
时间太久了，我有点不太记得了，我印象中是因为grpc协议传输的数据设置为了4M，而我传输的数据远超过4M，所以出错了。在这个代码里面有地方可以设置GRPC协议传输数据大小，不过我当时设置的时候可能没找对地方，没设置成功。
------------------ 原始邮件 ------------------
发件人:                                                                                "hyperledger/fabric-sdk-py"                                                                                @.>;
发送时间: 2023年11月27日(星期一) 晚上6:51
@.>;
@.@.>;
主题: Re: [hyperledger/fabric-sdk-py] "Missing 'proposalResponses' parameter in transaction request" (Issue #162)
我的问题跟你的问题一样。但我是获取数据时报的这个错误。
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.>
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.>

请问是在network.json文件里面改吗？
"orderers": {     "orderer.example.com": {       "url": "192.168.227.128:7050",       "grpcOptions": {         "grpc.ssl_target_name_override": "orderer.example.com",         "grpc-max-send-message-length": -1  // 无限制       },       "tlsCACerts": {         "path": "./crypto-config/ordererOrganizations/example.com/tlsca/tlsca.example.com-cert.pem"       }     }   },
但是改了后，重新启动程序还是报这个错误。

请问是在network.json文件里面改吗？
  "orderers": {
    "orderer.example.com": {
      "url": "192.168.227.128:7050",
      "grpcOptions": {
        "grpc.ssl_target_name_override": "orderer.example.com",
        "grpc-max-send-message-length": -1 // 无限制
      },
      "tlsCACerts": {
        "path": "./crypto-config/ordererOrganizations/example.com/tlsca/tlsca.example.com-cert.pem"
      }
    }
  },

但是改了后，重新启动程序还是报这个错误。

authors: Creazy-MR JessKXWL NonCover saikumar-neelam

repo: hyperledger/fabric-sdk-py


text:
Bump Go to 1.20.6

Bump Go to 1.20.6.

Broken Link Checker failure can be ignored. This check only runs when .github/workflows/broken-link-checker.yml is modified (as it was in this PR).

repo: hyperledger/fabric

license_source: bigquery


text:
Add ledgerutil to docs

All ledgerutil to docs.
Also remove idemixgen since it was moved to its own repository.

@satota2 Thanks, fixed!


text:
[Enhancement] Optimize block structure

Current design
Currently block has the following structure:
message Block {
  message Payload {
     repeated Transaction transactions = 1;
    uint32 tx_number = 2
    uint64 height = 3;
    bytes merkle_root = 4;
    bytes prev_block_hash = 5;
    uint64 created_time = 6;
   }

  Payload payload = 1;
  repeated Signature signatures = 2;
 }

where Transaction is another complex proto object.
It is stored in a ledger as raw file. One file = one block.
Assume we have a query "give me a transaction with hash H", and assume we build an indexing system to make queries efficient. In this case we make an index tx_hash -> block number to know the block number for each transaction.
Then, to query a single transaction, these actions must be performed:

find block with this transaction by looking at KV db (now Redis), normally O(1), if stored in hashmap.
given block number, query full block (read file, O(1) of ledger size)
for O(number of tx in block) search for given transaction blob.

IMO it is not efficient scheme, since query for specific transactions will be very frequent.
Enhancement proposal
Store whole block_store in postgres:
Note: for now, ignore field role.

block is hashed (and therefore signed) with naive stream serializer (no protobuf, no boost::serialize), eg
struct Block{
  uint64_t transactions;
  std::string tx_merkle_root;
  std::string prev_hash;
  uint64_t timestamp;
  std::string peer_merkle_root;
};

template <
    class CharT,
    class Traits = std::char_traits<CharT>
>
std::basic_istream<CharT, Traits>& operator<< (std::basic_istream<CharT, Traits>& stream, const Block& b){
  // explicit order
  stream << b.transactions
         << b.tx_merkle_root
         << b.prev_hash
         << b.timestamp
         << b.peer_merkle_root;
  return stream;
}

// just example, can be used separate class Serializer or Hasher.
Block b;
std::istringstream ss;
ss << b;
ss.str(); // serialized block, ready to be hashed and signed. Magic?

block has many signatures, 1-N  relation. therefore we need signature table with signature details. it is also possible to remove id field in signature table and make <block_id, pubkey> a primary key.

block itself does not store transactions, they are stored in a separate table Transaction. Current proposal does not include specific TX fields in DB, BUT it is strongly recommended NOT to store HASH => BLOB, but store <hash, txfields...>, because of efficient indexing and search.

to proove that transaction exists in specific block, merkle tree is used. merkle tree is stored as binary tree with max number of leafs = MAX TX PER BLOCK (2^14 is good start). It can be stored in postgres, or in any (possibly) more efficient on-disk data structure. It is important to store whole tree, because hash calculation is expensive by means of CPU time and query of intermediate nodes in tree is frequent operation.

It works like this:

transactions are pushed to leafs, from the left to the right.

merkle tree is calculated during block creation, after we determined which transactions should be in the block.

merkle tree is persisted on disk.

whenever anybody asks to proove that tx belongs to the block, we answer with a proof - a path from leaf (this tx) to the root, so that the one can calculate O(logN) hashes, obtain merkle root and compare it with tx_merkle_root from block, which is cryptographically signed.

we have a requirement to add and remove peers on-the-fly. One way to solve this is to keep a list of available peers in the block and sign it, to prevent fraud. Problem arises: how to do it efficiently in terms of space? Because peers list may not be changed frequently, many blocks will have the same array and this is expensive in terms of disk space.

To understand who should have signed the block at the moment of block creation -- another merkle tree is used (peer_merkle_tree). It is used to proove that specific peer existed in the ledger at the moment of block creation.
idea is the following:

we maintain KV peer_merkle_root -> [array of peer pubkeys] for all peer additions or removals. In other words, we maintain history of all peer_merkle_roots.
when new peer is added, we push his pubkey to the peer_merkle_tree. accordingly, when removed - we remove its pubkey from merkle tree, resulting in creation of new record (change) ini peer_merkle_roots.

Example: one asks who signed the block $given.

look at block $given, find peer_merkle_root
query array (lets call it ARR) of peer pubkeys from KV using peer_merkle_root from step above
PUBS=SELECT pubkey FROM signature where block_id = $given;.
if:

((len(ARR)-1) * 2. / 3.) <= len(PUBS)  - number of signatures is more than 2/3 * N
all([pubkey in ARR for pubkey in PUBS])- all pubkeys are in array of peers from ARR
then:
answer with PUBS

Example: one asks, if peer A signed block 5?

look at block, find peer_merkle_root
find peer A in array of pubkeys by key peer_merkle_root
if found => it is a proof that he could not have signed tx, but definitely existed in the ledger at the moment of block 5 creation.
SELECT * FROM signature where block_id = 5;

This prevents storing redundant info many times, since we store only hash of pubkeys existed in ledger.

I like it
p.s: sorry for being short on so long post

By doing so we can also discard using complex redis indexing and use postgresql indices

Bump

authors: Warchant l4l neewy

repo: hyperledger/iroha


text:
New logger trunk

Description of the Change
This trunk contains the new logger implementation fully integrated into the project. Additionally, the configuration file parsing was rewritten and related libraries (fmt & spdlog) were updated.

Benefits
New logger features, hidden libs & better config parser.

Commits 2f09018, 4241a1e, e940c49 and d1f2be94e were accidentally merged from #2072 without being squashed.

Can you please also write some docs about verbosity level here?..

Looks good but please fix mst_fuzz and status_fuzzing and torii_fuzzing targets.

These targets are outdated due to missing CI checks for them, and it has nothing to do with the new logger. So I tried to fix them in a separate PR: please see #2136.

authors: MBoldyrev neewy


text:
[feature] #3231: Monolithic validator

Description

No more chain of validators in core. Just one monolithic validator
Genesis new requires validator
Added Upgrade instruction
Recursive transaction and instruction validation moved to validator

Previously we checked instructions of one tx on Iroha side. Now it's a work for Runtime Permission Validator. However Runtime Validator still can accept Instruction as input, because it's required for WASM smartcontracts and triggers.
Transaction instructions need to be aplied to wsv in order to properly validate them (if one instrucion depends on another). This forces us to execute instructions on validator. It's kind of unexpected for a thing called Validator. So @appetrosyan suggests to rename it to Verifier, which will accept WSV and return the updated one. But I haven't done that in this PR, because such semantic change requires a lot of changes in all code base, including block.rs, main_loop.rs and etc.
I wonder what others think about that.

Linked issue

Closes #3231

Benefits

Checklist

[x] I've read CONTRIBUTING.md
[x] I've used the standard signed-off commit format (or will squash just before merging)
[ ] All applicable CI checks pass (or I promised to make them pass later)
[ ] (optional) I've written unit tests for the code changes
[ ] I replied to all comments after code review, marking all implemented changes with thumbs up

I'll squash commits into one when will be ready to merge


text:
[feature] #3974: Add subcommands into iroha_client_cli to edit domain metadata

Description
This PR adds subcommands that set and remove metadata from a domain.
Linked issue
Closes one of subtasks from #3974
Benefits
The users will be able to edit domain metadata using iroha_client_cli.
Checklist

[x] I've read CONTRIBUTING.md
[x] I've used the standard signed-off commit format (or will squash just before merging)
[ ] All applicable CI checks pass (or I promised to make them pass later)
[ ] (optional) I've written unit tests for the code changes
[ ] I replied to all comments after code review, marking all implemented changes with thumbs up

Pull Request Test Coverage Report for Build 6870107869

0 of 38 (0.0%)  changed or added relevant lines in 1 file are covered.
6893 unchanged lines in 128 files lost coverage.
Overall coverage decreased (-4.1%) to 55.373%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

client_cli/src/main.rs
0
38
0.0%

Files with Coverage Reduction
New Missed Lines
%

config/base/derive/src/view.rs
1
99.37%

config/src/block_sync.rs
1
95.0%

config/src/network.rs
1
93.75%

config/src/torii.rs
1
95.45%

config/src/wasm.rs
1
87.5%

core/src/smartcontracts/isi/block.rs
1
87.5%

config/src/kura.rs
2
79.41%

config/src/lib.rs
2
0.0%

ffi/src/option.rs
2
71.43%

config/src/genesis.rs
3
72.92%

Totals

Change from base Build 5423219773:
-4.1%

Covered Lines:
22156

Relevant Lines:
40012

💛  - Coveralls

@Erigara

should be covered by tests as well.

sure, I will do it here

you told during the daily that you don't like smt about API, what exactly?

The problem is that we specify the metadata value as a CLI argument so it's difficult to use. Here is another way - read metadata value from a file so we should specify a path to this file as a CLI argument. What do you think about it?

Closing in favor of #4175

authors: Erigara coveralls pesterev


text:
sawtooth cluster start error message

Error message output by 'sawtooth cluster start" when
a processor is not specified has been made more
specific, explaining where to find the processors
that come with Sawtooth Lake, etc.
Signed-off-by: Todd Ojala todd@bitwse.io

The original error message is insufficient. It provides no information on what should be specified after a -P argument or how to find a valid parameter. Even better if it provided a list of valid known options.

@cintel and @vaporos How about this compromise:
We can't provide a strict list of choices using the "choices" container of the argparse addarguments method. That would prevent the user from choosing their own home-grown transaction processors.
How about if the error message includes the current list of provided processors? We will need to try to keep this up to date, or add some kind of automation to create the list.
I will start by just a list of processors that needs to be manually updated.

Providing a list of the transaction processors provided would be good.

Since there is no natural list of TPs to display (what TPs are in core is completely irrelevant, as it may not match the installation), we should focus more on the text of the message being clear.  At minimum, "Use -P to specify one or more transaction processors".
We could also augment the usage statement for the command such that it describes this further in an epilog section.  Something like:
details:
The available transaction processors specified by -P depends upon the method (specified by -m).
When using docker, ... (and some hint about how to find them with docker ps).

@cintel and @vaporos  I have attempted to make a good error message and a good epilog that is accurate. Please take a look!

Great. So we have an OK from @dcmiddle . @vaporos  or @cintel ?

@vaporos and @cintel I took into account Shawn's feedback from last week.
Please take a look at this compromise, maybe we can close or merge this PR today! ;)

authors: cintel ojalatodd vaporos

repo: hyperledger/sawtooth-core


text:
[chore] A simpler PR template is needed

Description
Keep it simple.

Issue forms are not supported for pull requests.  link

So keep using .md template.

repo: hypertrons/hypertrons-crx


text:
Better unit test outputs

Docker output has no information on unit tests
We want to see each test and how it's passing.
Each test run
pass/fail status
On the docker build.
1 - change docker file to use "expanded" option for unit test
RUN cd hashed-wallet && flutter test -r expanded

2 - change docker build command to show all output
docker build --progress=plain --no-cache -t flutterdocker .

Note - this has been added the the v1.0.0_M1_00 branch
Once merged, will be fixed.

branch merged, this is fixed

repo: hypha-dao/hashed-wallet

license: MIT


text:
Add a Notion project document for Courses

Tasks

[ ]  Create a page in Notion
[ ] Add a link to this project board there
[ ] Add a link in the side panel of this project board back

Suggested problem statement
Problem
A big part of the reason people are interested in active organizations is so they can contact staff there to persue sales opportunites. When our staff are on calls with users it helps to be able to talk specifically about where they have good or poor traction within that organization.
A the moment our metrics are too high level, and don't provide any way to contact people at schools
Solution
We will integrate information about courses which has:

Contact details so staff can reach out
More fine grained stats about where activity to form the basis of conversations when reaching out
We will introduce a new board which provides as much data as we can on a given "grouping" (like a course or section)
This will allow you to navigate to it from organizations, and also to dive into sections from a course for example

Approach

We will expand the existing Report product to include data about courses and metrics for them
We will work out a way to access teacher emails in the interface while leaving them at rest in the regions they start in
We will act in an 80/20 way to get as much value as quickly as possible (even if we don't replicate every item on the page)
We will present working prototypes as quickly as possible
Then seek feedback on what, if anything, is required and missing

I think we know this is busy work to put into Notion. This ticket is probably enough.

repo: hypothesis/report


text:
Update chroot-script.sh

Per kubernetes/kubernetes#26038 this is needed to run kubelet on the RPi when installing https://github.com/kubernetes/kube-deploy/tree/master/docker-multinode. Would be nice to have this included by default since, I assume, this is a common use case.

@yonatan-schultz could you please add a test like https://github.com/hypriot/image-builder-rpi/blob/master/builder/test-integration/spec/hypriotos-image/cmdline_kernel_spec.rb#L8 for the new setting?

@DieterReuter you got it

Thanks, LGTM.

authors: DieterReuter yonatan-schultz

repo: hypriot/image-builder-rpi

license: mit


text:
I want to get the candidate column information of Fcitx5

I want to set the transparency of the candidate bar of Fcitx5 separately, but I can't get its title and other information. What should I do to get its title and other information?
I am not good at English,so I translated it

try these
windowrule=opacity 0.6 override 0.6 override,^(fcitx)$

this will match the candidates for xwayland applications

for wayland applications, classes would get disappeared, and I'm not sure whether if it's possible to match against initialClass

try these
windowrule=opacity 0.6 override 0.6 override,^(fcitx)$

this will match the candidates for xwayland applications

Thank you for your help! Have a nice day!

repo: hyprwm/Hyprland


text:
Fix breaking change in upstream wlroots (!4644)

https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4644
modified:   src/Compositor.cpp
Describe your PR, what does it fix/add?
wlr_renderer_get_dmabuf_texture_formats() got nuked in favour of wlr_renderer_get_texture_formats() with WLR_BUFFER_CAP_DMABUF
Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)
No.
Is it ready for merging, or does it need work?
No. It should only be merged if/when wlroots-hyprland picks up those commits.

please don't make MRs for future/pending wlroots breakages, I fix them alongside the bump commit.


text:
hyprbars: add default.nix

per request of @fufexan

Thank you!

authors: fufexan snehrbass

repo: hyprwm/hyprland-plugins


text:
Release/hy scale0.9.6.0.1

Added Null check to avoid NPE while building service status.

Committed in wrong branch

repo: hyscale/hyscale


text:
chore(deps): update pnpm to v8.15.1

This PR contains the following updates:

Package
Type
Update
Change

pnpm (source)
packageManager
patch
8.15.0 -> 8.15.1

Release Notes

pnpm/pnpm (pnpm)
v8.15.1
Compare Source
Patch Changes

Use the object-hash library instead of node-object-hash for hashing keys of side-effects cache #7591.
bundledDependencies should never be added to the lockfile with false as the value #7576.

Platinum Sponsors

Gold Sponsors

Our Silver Sponsors

Configuration
📅 Schedule: Branch creation - "every 7 day" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

Renovate Ignore Notification
Because you closed this PR without merging, Renovate will ignore this update (8.15.1). You will get a PR once a newer version is released. To ignore this dependency forever, add it to the ignoreDeps array of your Renovate config.
If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.

repo: hywax/muuto


text:
Decoding of strokes

The strokes are rendered from parameters to strokes and added to a canvas in the decode function
https://github.com/hzwer/ICCV2019-LearningToPaint/blob/5f62ffcb605654716efaf95cb4508c087bc01522/baseline/DRL/ddpg.py#L26
I've got a couple of questions regarding the procedure. Why does the decoder return
https://github.com/hzwer/ICCV2019-LearningToPaint/blob/5f62ffcb605654716efaf95cb4508c087bc01522/baseline/Renderer/model.py#L34 ? It is trained by comparing to the ground truth, why should it learn the inverse, instead of the actual image?
Why is the stroke then
https://github.com/hzwer/ICCV2019-LearningToPaint/blob/5f62ffcb605654716efaf95cb4508c087bc01522/baseline/DRL/ddpg.py#L28 ?
And why is it added to the canvas via https://github.com/hzwer/ICCV2019-LearningToPaint/blob/5f62ffcb605654716efaf95cb4508c087bc01522/baseline/DRL/ddpg.py#L36 ?
I don't understand why you would do the 1 - stroke at every step in this chain. Also the canvas is initialized to all zeros. Is the canvas * (1 - stroke[:, k]) in canvas = canvas * (1 - stroke[:, k]) + color_stroke[:, k] really necessary? stroke is included in color_stroke anyway.
Am I missing something? Thanks for any help!

Before the convolution, the image boundary needs to be padded with 0. Whether the stroke is white or black has a minor effect on the boundaries of the image generated by the decoder.
canvas = canvas * (1 - stroke[:, i]) + color_stroke[:, i]
The stroke is not a 01 mask, the stroke is translucent. So you need to mix two parts.

Thanks for the quick reply! So you're saying that the Decoder is operating on a black background, then for the color mixing it is converted to white background. Why is it multiplied with the canvas in canvas = canvas * (1 - stroke[:, i]) + color_stroke[:, i] with black background again? After all color_stroke already includes it anyways color_stroke = stroke * x[:, -3:].view(-1, 1, 1, 3).

Adding strokes does not directly cover an area. Assuming that the value of stroke is 0.5, multiplying an area by 0.5, plus color_stroke, means adding a stroke with a transparency of 50.

Ok, thanks a lot. I understand now!

authors: hzwer kampelmuehler


text:
Update content following review

Context
This is just a few small content changes to the prototype following a review with @judewebby.
Changes proposed in this pull request

Add a "Register your interest" link to the /get-involved page
Rather than provide a URL on the schema upload confirmation, it now says "We will let you know once it is ready".
Remove "i.AI" from the header title
Remove the "Prototype" link from the footer"

Visit and check the following pages in the prototype:

/get-involved
/upload-success

One q about the URL! (For me it's localhost:3000)

Thank you - you're right. I'll update and rebase.

repo: i-dot-ai/consultation-analyser


text:
Catch and display timeout errors communicating with core-api during message streaming.

Context
Fix for REDBOX-415.
When core-api fails to build a chat response, the front end currently doesn't show anything to the user.
Changes proposed in this pull request
When core-api fails to build a chat response, the front end now shows an error message.

Guidance to review
Relevant links
https://technologyprogramme.atlassian.net/browse/REDBOX-415
Things to check

[ ] I have added any new ENV vars in all deployed environments
[x] I have tested any code added or changed
[ ] I have run integration tests

This could do with some stying and content design  love, but it's probably good enough for now.

repo: i-dot-ai/redbox-copilot


text:
missingKey en zod key key

💥 Regression Report
I am unable to change the language with the using of the LanguageDetector package, When i set the fallback langauge as en or ar it works pretty fine but after it is being set if i try to change the language that doesn't work even tho i see this log when i set debug: true
// logs on each request that i have Accept-Language Header set to ar
i18next: languageChanged en
i18next: languageChanged ar
i18next::translator: missingKey en zod email email

Config
// configure dotenv before every thing, even imports
import * as dotenv from 'dotenv';
import { join, resolve } from 'path';
dotenv.config({ path: resolve(__dirname, '.env') });

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import i18next from 'i18next';
import enTranslations from 'zod-i18n-map/locales/en/zod.json';
import { z } from 'zod';
import { makeZodI18nMap } from 'zod-i18n-map';
import languageDetector from 'i18next-http-middleware';
import i18nextBackend from 'i18next-fs-backend';
import arTranslations from 'zod-i18n-map/locales/ar/zod.json';
import enTranslations from 'zod-i18n-map/locales/en/zod.json';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  app.use(languageDetector.handle(i18next));

    await i18next
      .use(i18nextBackend)
      .use(languageDetector.LanguageDetector)
    .init({
      debug: true,
      supportedLngs: ['en', 'ar'],
      fallbackLng: 'en',
      resources: {
        ar: { zod: arTranslations },
        en: { zod: enTranslations },
      },
    });

  z.setErrorMap(makeZodI18nMap({ ns: 'zod', t: i18next.t }));
  app.use(compression());
  await app.listen(3000);
}
bootstrap();

Expected behavior
to return the message as 'ar' instead of the fallbackLng
Your Environment

runtime version: Latest Nestjs
i18next version: 23.5.1
os: Windows
zod-i18n-map: 2.20.0

Debug
i18next: languageChanged en
i18next: initialized {
  debug: true,
  initImmediate: true,
  ns: [ 'translation' ],
  defaultNS: [ 'translation' ],
  fallbackLng: [ 'en' ],
  fallbackNS: false,
  supportedLngs: [ 'en', 'ar', 'cimode' ],
  nonExplicitSupportedLngs: false,
  load: 'all',
  preload: false,
  simplifyPluralSuffix: true,
  keySeparator: '.',
  nsSeparator: ':',
  pluralSeparator: '_',
  contextSeparator: '_',
  partialBundledLanguages: false,
  saveMissing: false,
  updateMissing: false,
  saveMissingTo: 'fallback',
  saveMissingPlurals: true,
  missingKeyHandler: false,
  missingInterpolationHandler: false,
  postProcess: false,
  postProcessPassResolved: false,
  returnNull: false,
  returnEmptyString: true,
  returnObjects: false,
  joinArrays: false,
  returnedObjectHandler: false,
  parseMissingKeyHandler: false,
  appendNamespaceToMissingKey: false,
  appendNamespaceToCIMode: false,
  overloadTranslationOptionHandler: [Function: handle],
  interpolation: {
    escapeValue: true,
    format: [Function: bound format],
    prefix: '{{',
    suffix: '}}',
    formatSeparator: ',',
    unescapePrefix: '-',
    nestingPrefix: '$t(',
    nestingSuffix: ')',
    nestingOptionsSeparator: ',',
    maxReplaces: 1000,
    skipOnVariables: true
  },
  resources: { ar: { zod: [Object] }, en: { zod: [Object] } },
  ignoreJSONStructure: true
}

Usually next.hs is doing the language detection...
Please provide a reproducible example repository.

authors: adrai mohrazzak


text:
Support linguijs

Is best if this can support https://lingui.dev/
Thanks author.

I'm not sure I understand. Is there an issue you're running into specifically when trying to use lingui?
This library is agnostic to what i18n library you use. It doesn't matter if you want to use react-intl, lingui, i18next, etc... The next-i18n-router library simply provides internationalized routing. Nothing more. If lingui.js works in Next.js, then you can certainly use it with this library.
I know right now we only have an example for react-intl integration, but we will be adding more examples for other i18n libraries in the near future! We also welcome anyone to make a PR into our examples folder with other library integrations.

Going to close this one since all i18n libraries are inherently supported.