Останнім часом багато хто каже, що дані на ланцюгу «застрягають», але насправді це не обов’язково через повільність мережі, здебільшого це через ваш рівень індексатора/субграфа/RPC, який задихається. Субграфу потрібно сканувати блоки + аналізувати події, при зустрічі з реорганізацією або відтворенням вузла він тимчасово повертається назад для відновлення; обмеження швидкості RPC також цілком реальні, якщо ви відкриваєте занадто багато одночасних запитів, відповіді починають «пливти», а ще більше дратує те, що фронтенд може кешувати старі результати, змушуючи вас думати, що ви бачите галюцинації. Кажучи просто, дані — це не «реальні часи», а «наскільки можливо близько до реального часу». Я не шкодую про те, що… колись мене за nonce застрягли, я з усією силою налаштував скрипт так, щоб автоматично знижувати швидкість повторних спроб і переключатися на резервний RPC, інакше, мабуть, досі б кричав на мережу. До речі, дивлячись на останні сварки щодо NFT-роялті, багато з цих «угод/постанов» також піддаються цим затримкам, тож не поспішайте критикувати один одного, спершу переконайтеся, що джерело даних не «збісилося»… В будь-якому разі, коли я бачу затримки, перша реакція — перевірити обмеження швидкості, потім висоту індексу.