История о том, как я доступность Hyperliquid улучшил.

Напомню, что работал с проектом где-то с февраля 2024. Интерфейс был удобным и понятным / доступным в основном.

Единственное, в чём была сложность - это переводы между spot и perps.

Представьте 2 элемента (у меня две строки подряд):

spot
perps

И что между ними где-то там затесалась иконка, по которой надо нажать для переключения.

(если непонятно, попробую проиллюстрировать при помощи ИИ).

Естественно иконка никак не озвучивалась, и я не мог по ней нажать.
Приходилось просить зрячих, но не всегда такая возможность была. А это неудобно.

Через некоторое время написал в Discord, создав тикет.

Там попросил улучшить доступность, реализовав переключение между спотом и перп-балансами кликом по элементу с клавиатуры.

То есть чтоб было так:
spot
perp

Нажимаю по элементу с этими двумя словами.

И становится так:
perp
spot

Проходит месяц-полтора.
Пишу вновь: когда сделают.
Мне отвечают, что пока другие приоритеты, но обязательно сделают.

Вот только уже веры у меня особо не было в это.

Тем было радостнее ещё через 1-2 месяца увидеть это изменение!

Как было классно нажимать и переключаться для перевода токенов между балансами, а также для стейкинга / онстейкинга (там та же проблема была)!

Сейчас пользуюсь 100% доступным интерфейсом, и очень доволен.

P. S. Поражает, когда в perp дексах делают плохо доступными даже установку стоп-лосса с тейк-профитом.

Напишите в комментариях, про доступность каких проекты было бы интересно вам почитать ещё.
Может хотели бы узнать о доступности Aster или других perp dex? Может о чём-то ином?

😎 Незрячий web3 программист (подписаться)
Чат | бот

📟 Прилетело из @blind_dev

Без ЭТИХ языков WEB3 НЕ СУЩЕСТВУЕТ

youtu.be/U5rzrFIhXEQ
youtu.be/U5rzrFIhXEQ
youtu.be/U5rzrFIhXEQ

Изучаем

📟 Прилетело из @code_vartcall

Атака майнеров. Часть 2

Используется ли block.timestamp для операций, чувствительных ко времени?

Майнеры могут манипулировать block.timestamp на несколько секунд, что может повлиять на логику контрактов, зависящих от времени.

Как предотвратить: используйте block.number вместо временных меток для критически важных операций, связанных со временем, или убедитесь, что допустимая погрешность манипуляций приемлема.
‍
block.timestamp представляет время, которое майнер предлагает для блока. Хотя оно обычно точное, майнеры имеют некоторую свободу для его корректировки. Эта свобода допускает потенциальные уязвимости в логике, чувствительной ко времени, такой как аукционы или периоды стейкинга.

Эта уязвимость является прямым следствием манипуляций майнеров, отражая их способность влиять на создание блоков. Хотя майнеры не могут устанавливать произвольные временные метки, они имеют некоторый контроль в рамках правил консенсуса. В Ethereum это примерно +/- 900 секунд (15 минут), хотя точный диапазон может варьироваться в зависимости от блокчейна.

Представьте себе аукцион, на котором майнер сдвигает временную метку в пользу своей ставки или ставки своего союзника. Это может привести к несправедливым преимуществам, таким как преждевременное завершение аукциона или манипулирование процессом торгов.

Посмотрите на пример:

pragma solidity ^0.8.0;


// SPDX-License-Identifier: UNLICENSED
contract Auction {
    uint public auctionEndTime;
    address public highestBidder;
    uint public highestBid;
    mapping(address => uint) public pendingReturns;
    bool public ended;


    event BidPlaced(address bidder, uint amount);
    event AuctionEnded(address winner, uint amount);


    constructor(uint _duration) {
        auctionEndTime = block.timestamp + _duration; // Vulnerability!
    }


    function isAuctionEnded() public view returns (bool) {
        return block.timestamp >= auctionEndTime; // Vulnerable comparison!
    }


    function bid() public payable {
        require(!isAuctionEnded(), "Auction has ended");
        require(msg.value > highestBid, "Bid not high enough");


        if (highestBid > 0) {
            pendingReturns[highestBidder] += highestBid;
        }


        highestBidder = msg.sender;
        highestBid = msg.value;
        emit BidPlaced(msg.sender, msg.value);
    }


    function endAuction() public {
        require(!ended, "Auction already ended");
        require(isAuctionEnded(), "Auction not yet ended");


        ended = true;
        emit AuctionEnded(highestBidder, highestBid);
    }


    function withdraw() public returns (bool) {
        uint amount = pendingReturns[msg.sender];
        if (amount > 0) {
            pendingReturns[msg.sender] = 0;


            // Use call instead of transfer for better compatibility
            (bool success, ) = payable(msg.sender).call{value: amount}("");
            require(success, "Transfer failed");
        }
        return true;
    }
}

В этом аукционном контракте время окончания аукциона (auctionEndTime) определяется как block.timestamp + _duration. Майнер может слегка изменить block.timestamp, чтобы досрочно завершить аукцион или отложить его. Он может отложить его настолько, чтобы его ставка была включена в блок, или ускорить его, чтобы исключить конкурирующую ставку.

Вместо того, чтобы полагаться непосредственно на block.timestamp, рассмотрите возможность использования block.number.

pragma solidity ^0.8.0;


contract FixedAuction {
    uint256 public auctionEndBlock;
    uint256 public blockDuration;


    constructor(uint256 _blockDuration) {
        auctionEndBlock = block.number + _blockDuration;
        blockDuration = _blockDuration; // Duration of auction in blocks
    }


    function finalizeAuction() public {
        require(block.number >= auctionEndBlock, "Auction is not yet over.");
        // Distribute funds
    }
}

📟 Прилетело из @solidityset

В этом примере FixedAuction мы используем block.number вместо block.timestamp для определения окончания аукциона. Это делает время проведения аукциона предсказуемым и устойчивым к манипуляциям майнеров с block.timestamp.

Однако майнер может вообще отказаться от добычи блоков, что задержит окончание аукциона, хотя это и является менее прямой формой манипуляции. Кроме того, использование block.number делает аукцион зависимым от скорости создания блоков. Если время блоков несовместимо, продолжительность аукциона может немного варьироваться в реальном времени.

Если требуется более детальное и согласованное время, рассмотрите возможность использования оракула Chainlink, но имейте в виду повышенную сложность и затраты на газ.

В целом рекомендуется избегать разработки функций, чувствительных ко времени с точностью до секунд, поскольку майнеры могут манипулировать временными метками блоков в пределах допустимых значений (обычно ±15 секунд в Ethereum). Смарт-контракты должны реализовывать механизмы, основанные на времени, с достаточными буферными периодами, чтобы предотвратить экономическую эксплуатацию посредством незначительных корректировок временных меток.

#miner #mev

📟 Прилетело из @solidityset

Кладезь Знаний | Мысли вслух

За последние 2 года ведения этого телеграм-канала я накопил сотни полезных материалов для разработчиков: от начинающих до людей, которые хотят найти свою первую работу в web3

И как свойственно контенту - он устаревает и у меня нету желания мониторить и обновлять то, что я писал 2-3 года назад!

Поэтому я создал свой кладезь знаний, свою общину, свой Олимп разработчиков web3

Задача была одна - объединение таких-же амбициозных личностей в одном месте, для совместного создания проектов и инструментов которыми в результате будут пользоваться сотни тысяч и миллионы пользователей

Сегодня я представляю Олимп - наше место силы и базы знаний о web3

На Олимпе:

Гайды с нуля до первой работы в web3

Мои Закрытые Материалы, как вы могли видеть в этом посте

Гайды с нуля до Solidity

Гайды с нуля до Solana

Гайды по взаимодействию с криптой с нуля

И в последующем прямые эфиры, совместные проекты, живые встречи, игры и веселье

Цена: $99 / Пожизненно

Каждый год 31 декабря в 23:03 цена будет повышаться

Оплата и прочие вопросы - @jerskrew

Пора собираться на Олимп!

📟 Прилетело из @code_vartcall

🏔 Все Про Олимп

t.me/goto_olympys

📟 Прилетело из @code_vartcall

RPC с НУЛЯ: как работает сердце блокчейна

youtu.be/g34Lk2SPIoc
youtu.be/g34Lk2SPIoc
youtu.be/g34Lk2SPIoc

Время блокчейна!

📟 Прилетело из @code_vartcall

ПЕРВЫЙ СКРИПТ для БЛОКЧЕЙНА: проще, чем ты думаешь

youtu.be/c4tsb_tubHs
youtu.be/c4tsb_tubHs
youtu.be/c4tsb_tubHs

Применяем!

📟 Прилетело из @code_vartcall

Как начать свой путь в блокчейн разработке

Пошаговый план из моих последних видео:

1. Зачем нам web3 разработка

2. Языки программирования для web3

3. Получение своего первого ключа доступа к блокчейну

4. Написание первого скрипта

Сделаем контент лучше:

На 1 час выключаю платные сообщения, поэтому:

Напишите в комментариях, что улучшить в видео, чего вам не хватило в последних материалах

📟 Прилетело из @code_vartcall

Как начать свой путь в блокчейн разработке

Пошаговый план из моих последних видео:

1. Зачем нам web3 разработка

2. Языки программирования для web3

3. Получение своего первого ключа доступа к блокчейну

4. Написание первого скрипта

Сделаем контент лучше:

На 1 час выключаю платные сообщения, поэтому:

Напишите в комментариях, что улучшить в видео, чего вам не хватило в последних материалах

📟 Прилетело из @code_vartcall

#новости этой недели: пишу статью с вопросами ко мне, другое и опрос.

1. Как написал в заголовке поста, пишу статью с вопросами ко мне, как к незрячему программисту в крипте.
Если у вас есть что спросить, пишите в комментариях. Уникальные вопросы доавлю в статью.

2. Прошу ответить на опрос ниже. Задумался, что может стоит переименовать канал? Например, назвать "Незрячий программист в крипте".

3. Опубликовал во вторник анонс ноябрьского события The trends, но оказалось, что они не смогут меня сопроводить туда и обратно.
Поэтому удалил.

4. Отдыхаю. Из-за этого нет крупных статей с обзорами.

Всё.
Хорошего дня!

😎 Незрячий web3 программист (подписаться)
Чат | бот

📟 Прилетело из @blind_dev

Атака майнеров. Часть 3

Использует ли контракт свойства блока, такие как временная метка или сложность, для генерации случайных чисел?

Описание: Свойства блока (временная метка, сложность) и другие предсказуемые значения не должны использоваться для генерации случайных чисел, поскольку на них могут влиять или предсказывать майнеры.

Исправление: Вместо этого используйте безопасный источник случайных чисел, такой как Chainlink VRF, схемы commit-reveal или механизм рандомизации с доказанной справедливостью.

Настоящая случайность (randomness) в блокчейне – это сложно. block.timestamp и block.difficulty на первый взгляд могут казаться случайными, но майнеры могут влиять на них, делая результат предсказуемым.

Майнеры могут манипулировать block.timestamp в рамках правил консенсуса, и хотя они имеют очень ограниченный краткосрочный контроль над block.difficulty, полагаться на них в критически важных для безопасности логических операциях – в целом плохая идея.

Представьте себе лотерею, в которой майнер заранее знает выигрышный номер. Не совсем честная игра. Опять же, это относится к манипуляциям майнеров, когда они используют свое влияние для получения преимущества.

Давайте посмотрим на несовершенный лотерейный контракт:

pragma solidity ^0.8.0;


// SPDX-License-Identifier: UNLICENSED


contract Lottery {
    address public winner;


    function pickWinner() public {
        // Vulnerable randomness generation using block.timestamp
        uint256 randomNumber = uint256(block.timestamp) % 100;
        if (randomNumber == 7) {
            winner = msg.sender;
        } else {
            winner = address(0);
        }
    }


    function getBlockTimestamp() public view returns (uint256) {
        return block.timestamp;
    }
}

Здесь pickWinner использует block.timestamp для генерации «случайного» числа. Злоумышленник может изменить временную метку блока, содержащего транзакцию pickWinner, повлияв на результат и сфальсифицировав лотерею.

Вместо того, чтобы полагаться на легко манипулируемые свойства блока, используйте безопасный источник случайности, такой как Chainlink VRF, который предоставляет проверяемое и непредсказуемое случайное число, обеспечивая справедливость и предотвращая манипуляции. Свойства блока, такие как block.prevrandao, также лучше, чем block.timestamp, но все же не следует полагаться на них из-за возможности их устаревания.

📟 Прилетело из @solidityset

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;


import {VRFConsumerBaseV2Plus} from "@chainlink/contracts/src/v0.8/vrf/dev/VRFConsumerBaseV2Plus.sol";
import {VRFV2PlusClient} from "@chainlink/contracts/src/v0.8/vrf/dev/libraries/VRFV2PlusClient.sol";


/**
 * @noscript SecureLottery
 * @notice A lottery contract using Chainlink VRF V2.5 for verifiable randomness
 * @dev This is an example contract and should not be used in production without proper auditing
 */
contract SecureLottery is VRFConsumerBaseV2Plus {
    // Chainlink VRF configuration
    uint256 public s_subnoscriptionId;
    bytes32 public keyHash = 0x787d74caea10b2b357790d5b5247c2f63d1d91572a9846f780606e4d953677ae; // Sepolia gas lane
    uint32 public callbackGasLimit = 100000;
    uint16 public requestConfirmations = 3;
    uint32 public numWords = 1;


    // Lottery state variables
    uint256 public randomNumber;
    address public winner;
    mapping(uint256 => bool) public requestIds;
    uint256 public lastRequestId;


    // Events
    event RandomnessRequested(uint256 requestId);
    event WinnerSelected(address winner, uint256 randomNumber);


    /**
     * @param subnoscriptionId Chainlink VRF subnoscription ID
     * @param vrfCoordinator Address of the VRF Coordinator contract
     */
    constructor(
        uint256 subnoscriptionId,
        address vrfCoordinator
    ) VRFConsumerBaseV2Plus(vrfCoordinator) {
        s_subnoscriptionId = subnoscriptionId;
    }


    /**
     * @notice Request random number from Chainlink VRF
     * @param useNativePayment Whether to pay in native tokens (true) or LINK (false)
     * @return requestId The ID of the randomness request
     */
    function requestRandomWinner(bool useNativePayment) external returns (uint256 requestId) {
        // Request randomness from Chainlink VRF
        requestId = s_vrfCoordinator.requestRandomWords(
            VRFV2PlusClient.RandomWordsRequest({
                keyHash: keyHash,
                subId: s_subnoscriptionId,
                requestConfirmations: requestConfirmations,
                callbackGasLimit: callbackGasLimit,
                numWords: numWords,
                extraArgs: VRFV2PlusClient._argsToBytes(
                    VRFV2PlusClient.ExtraArgsV1({
                        nativePayment: useNativePayment
                    })
                )
            })
        );


        requestIds[requestId] = true;
        lastRequestId = requestId;
        emit RandomnessRequested(requestId);
        return requestId;
    }


    /**
     * @notice Callback function called by VRF Coordinator when randomness is fulfilled
     * @param requestId The ID of the randomness request
     * @param randomWords The random words generated by Chainlink VRF
     */
    function fulfillRandomWords(
        uint256 requestId,
        uint256[] calldata randomWords
    ) internal override {
        require(requestIds[requestId], "Request not found");
        require(randomWords.length > 0, "Random words array is empty");


        // Process the random value
        randomNumber = randomWords[0] % 100; // Example: limit to 0-99 range


        // Lottery winner selection logic would go here
        // For example, if you have participants in an array:
        // winner = participants[randomNumber % participants.length];


        emit WinnerSelected(winner, randomNumber);
    }


    /**
     * @notice Get the status of a VRF request
     * @param requestId The ID of the randomness request
     * @return exists Whether the request exists
     */
    function getRequestStatus(uint256 requestId) external view returns (bool exists) {
        return requestIds[requestId];
    }
}

📟 Прилетело из @solidityset

Этот контракт SecureLottery использует Chainlink VRF для генерации действительно случайного числа. Функция requestRandomWords запрашивает случайное число у службы Chainlink VRF. Функция fulfillRandomWords (которая ДОЛЖНА присутствовать при наследовании от VRFConsumerBaseV2Plus) получает случайное число и использует его для определения победителя. Это обеспечивает справедливый и непредсказуемый результат лотереи.

Использование Chainlink VRF влечет за собой внешние зависимости и затраты на газ. Кроме того, требуется настроить подписку на Chainlink VRF и управлять связанными с ней сборами. Однако эти затраты часто являются оправданной платой за повышенную безопасность и справедливость.

#miner #mev

📟 Прилетело из @solidityset

Сентябрь 2025

Разберем все самые важные события и обновления этого месяца

Контент:

Лучший сайт для изучения WEB3

Зачем тебе 200 тг-каналов, когда есть Twitter Списки

400 000 строк кода X: что скрывает алгоритм рекомендаций

Зачем я ВЛЕЗ в WEB3?

Без ЭТИХ языков WEB3 НЕ СУЩЕСТВУЕТ

RPC с НУЛЯ: как работает сердце блокчейна

ПЕРВЫЙ СКРИПТ для БЛОКЧЕЙНА: проще, чем ты думаешь

Запуск закрытого сообщества - Олимп

Последние 4 видео решил сделать в новом формате, накиньте фитбек, что улучшить, за самые интересные обновления отправлю файл - как начать свой путь в web3

📟 Прилетело из @code_vartcall

ШОБ ВЫ ПАНИМАЛИ

Пол дня разбирался с сейлом YB на legion. Если честно, это один из самых странных и глупых сейлов, которые я видел.

Контракт совершенно не приспособлен для фкфс:

1) Ончейн таймстемп старта не зашит. Когда бек разрешит, тогда и стартанет сейл :) Может стартануть на 15 минут раньше объявленого времени, например

2) Кепка сверху не ограничена. То есть туда могут накидать сильно больше 3кк. Как они будут распределять фкфс аллоки? Слишком много вопросов и слишком мало ответов

3) Контракт не проверяет ничего кроме подписи от бека. 1 кош может хоть лям закинуть))

4) Есть шанс, что на сейле подсунут другой контракт, от чего все скриптеры улетят в ханипот (маловероятно, но все же)

5) Для фкфс в эфире надо газануть. Не исключаю, что результаты этого фкфс отменят, деньги рефанднут, но газ никто не возместит


Вывод?
На 99% уверен, что будет как с фуелом (миша всё хуйня, давай по новой)
Честно, хочу скипнуть, попробовать только руками. Несмотря даже на готовый софт, я уверен, что меня наебут (as usual)

Что думаете сами вообще?

📟 Прилетело из @findmeonchain

Атака майнеров. Часть 4

Зависит ли логика контракта от порядка транзакций?

Описание: Майнеры контролируют порядок транзакций и могут использовать это для атак типа «фронт-раннинг», «бэк-раннинг» или «сэндвич».

Устранение: Реализуйте защиту, позволяя пользователям указывать приемлемые результаты, которые отменяют транзакции в случае нарушения.

Майнеры определяют порядок включения транзакций в блок. Хотя майнеры обычно отдают приоритет транзакциям с более высокими ценами на газ, они не обязаны этого делать. Это позволяет злонамеренным майнерам (или сложным ботам) стратегически упорядочивать транзакции в своих интересах. Такое использование может привести к фронтран, бекран или сэндвич атакам. Эти атаки используют манипуляции с порядком транзакций для извлечения выгоды.

Представьте себе децентрализованную биржу (DEX). Майнер видит в мемпуле крупный ордер на покупку определенного токена. Он может вставить свой собственный ордер на покупку перед крупным ордером (фронт-раннинг), что приведет к росту цены. Затем он может вставить свой ордер на продажу после крупного ордера (бэк-раннинг или сэндвич-атака), извлекая прибыль из роста цены, вызванного первоначальной сделкой.

Вот упрощенная уязвимая DEX:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.13;


import "@openzeppelin/contracts/token/ERC20/ERC20.sol";


// Simple ERC20 token for testing
contract TestToken is ERC20 {
    constructor(string memory name, string memory symbol, uint256 initialSupply) ERC20(name, symbol) {
        _mint(msg.sender, initialSupply);
    }
}


// Simplified DEX that's vulnerable to front-running
contract VulnerableDEX {
    TestToken public tokenA;
    TestToken public tokenB;
    uint public reserveA;
    uint public reserveB;


    constructor(address _tokenA, address _tokenB) {
        tokenA = TestToken(_tokenA);
        tokenB = TestToken(_tokenB);
    }


    // Initialize liquidity
    function addLiquidity(uint amountA, uint amountB) external {
        tokenA.transferFrom(msg.sender, address(this), amountA);
        tokenB.transferFrom(msg.sender, address(this), amountB);
        reserveA += amountA;
        reserveB += amountB;
    }


    // Calculate output amount for a given input
    function _calculateSwapOutput(address tokenIn, uint amountIn) internal view returns (uint amountOut) {
        require(tokenIn == address(tokenA) || tokenIn == address(tokenB), "Invalid token");


        bool isTokenA = tokenIn == address(tokenA);


        if (isTokenA) {
            amountOut = (reserveB * amountIn) / (reserveA + amountIn);
            require(amountOut < reserveB, "Insufficient liquidity");
        } else {
            amountOut = (reserveA * amountIn) / (reserveB + amountIn);
            require(amountOut < reserveA, "Insufficient liquidity");
        }


        return amountOut;
    }


    // Execute the swap with pre-calculated output
    function _executeSwap(address tokenIn, uint amountIn, uint amountOut, address sender) internal {
        bool isTokenA = tokenIn == address(tokenA);


        if (isTokenA) {
            tokenA.transferFrom(sender, address(this), amountIn);


            // Update reserves
            reserveA += amountIn;
            reserveB -= amountOut;


            // Transfer output tokens to the user
            tokenB.transfer(sender, amountOut);
        } else {
            tokenB.transferFrom(sender, address(this), amountIn);


            reserveB += amountIn;
            reserveA -= amountOut;


            tokenA.transfer(sender, amountOut);
        }
    }


    // Vulnerable swap function (no minimum output)
    function swap(address tokenIn, uint amountIn) external returns (uint amountOut) {
        // Calculate the expected output
        amountOut = _calculateSwapOutput(tokenIn, amountIn);


        // Execute the swap
        _executeSwap(tokenIn, amountIn, amountOut, msg.sender);


        return amountOut;
    }
}

📟 Прилетело из @solidityset

В этом контракте VulnerableDEX функция обмена не имеет защиты от проскальзывания, что делает ее уязвимой для атак типа «сэндвич». Эти атаки являются формой эксплуатации максимально извлекаемой стоимости (MEV), при которой прибыль извлекается путем манипулирования порядком транзакций.

Когда жертва отправляет транзакцию обмена в мемпул, опытные поисковики MEV выявляют возможность и выполняют трехэтапную атаку:

1. Фронтранинг: сначала злоумышленник размещает транзакцию на покупку целевого актива, намеренно завышая цену.
‍
2. Транзакция жертвы: своп жертвы выполняется по этой искусственно завышенной цене, и она получает меньше токенов, чем ожидалось, из-за отсутствия гарантий минимального выхода.
‍
3. Бэкранинг: злоумышленник продает ранее приобретенные токены по более высокой цене, созданной транзакцией жертвы, получая разницу в цене в качестве прибыли.

Хотя любой участник, отслеживающий mempool, может осуществлять атаки типа «сэндвич», производители блоков обладают привилегированными возможностями по упорядочиванию транзакций, что позволяет им осуществлять такие атаки с большей степенью уверенности.

Стратегии смягчения последствий зависят от конкретного контекста, но в целом защита от проскальзывания предотвращает атаки типа «сэндвич», гарантируя, что транзакция жертвы не будет выполнена по невыгодной цене. Позвольте пользователям указывать максимальное проскальзывание, которое они готовы допустить при совершении сделки. Если цена выходит за пределы этого порога, транзакция отменяется. Это защищает пользователей от атак типа «сэндвич».

Вот пример защиты от проскальзывания, которая смягчает последствия атаки типа «сэндвич», описанной в тесте выше.

// Secure swap function with minimum output requirement
    function swapWithMinimumOutput(
        address tokenIn,
        uint amountIn,
        uint minAmountOut
    ) external returns (uint amountOut) {
        // Calculate the expected output
        amountOut = _calculateSwapOutput(tokenIn, amountIn);


        // Check slippage before executing the swap
        require(amountOut >= minAmountOut, "Slippage too high");


        // Execute the swap
        _executeSwap(tokenIn, amountIn, amountOut, msg.sender);


        return amountOut;
    }

#miner #mev

📟 Прилетело из @solidityset