Blockgrid - дальнейшее развитие блокчейна.

[Vitalik Kuliev]

Добрый день.

Представляю сообществу whitepaper по улучшенной версии блокчейна. В данной архитектуре данные распределяются по многим нодам в сети, благодаря чему возможно на 1-2 порядка увеличить количество операций в сравнении с блокчейном. Blockgrid может быть использован для новых проектов, в которых не хватает производительности блокчейна.

https://docs.google.com/document/d/1Wnepzxh_bmKM6BGPYdMr_te4FOe60V_na3DzIymIswo/edit?usp=sharing

[ftrmsltcsrp]

Добрый день.

Представляю сообществу whitepaper по улучшенной версии блокчейна. В данной архитектуре данные распределяются по многим нодам в сети, благодаря чему возможно на 1-2 порядка увеличить количество операций в сравнении с блокчейном. Blockgrid может быть использован для новых проектов, в которых не хватает производительности блокчейна.

https://docs.google.com/document/d/1Wnepzxh_bmKM6BGPYdMr_te4FOe60V_na3DzIymIswo/edit?usp=sharing

Проблема биткоина(блокчейна) не в том, что там 3tps и что сеть моментально встанет раком как только им будет пользоваться аудиторию чуть большая, чем в сельхозбанке какого-нибудь мухосранского райцентра.


Проблема в сравнении с визой - это время подтверждения транзакций. Пошел в макдак - сунул карту и получил чем через 1с. С битком же пошел - сунул карту и получил пустоту и авось минут через 10 он родит подтверждение. Одно.



Любая распределённая сеть по умолчанию невозможна и не состоятельна. Куда новая нода стучит при запуске? Неужели к коллективному разуму сети? Что из себя представляет сейчас сеть? Пару центральных нод-майнингпуллов. Никакой централизации нет.




Сама "идея" примитивна донельзя - "давайте вместо одной сети сделаем 100500 и тогда надо хранить каждому только одну из 100500", но опять же идея обречена на неудачу, ибо должны быть возможны кросстранзакции, а значит рано или поздно сеть полностью сольётся. А сольётся настолько, что такая организация потеряет профит уже через неделю. Можно пойти ещё дальше и разделить сеть на N сетей для каждого адреса.


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




Децентрализованная архитектура не состоятельна, хотя даже сейчас она существует только в рекламных буклетиках и розовых мечтах "энтузиастов". Повторю ещё раз - всё сведётся( и уже совдится) к набору мастернод-арбитров, которые и будут заниматься верификацией. Как они будут определятся не важно.



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

Опять же эта очередная пыль в глаза, а реальная проблема косвенно указана в вашей работе. Сеть работает на пределе возможностей архитектуру биткоина и заддосить её не стоит ничего. Даже если биткоин и останется никому в рамках мира не нужным увеличение способности сети нужно не столько для роста, а сколько для стабильности сети.

[Vitalik Kuliev]

Сама "идея" примитивна донельзя - "давайте вместо одной сети сделаем 100500 и тогда надо хранить каждому только одну из 100500", но опять же идея обречена на неудачу, ибо должны быть возможны кросстранзакции, а значит рано или поздно сеть полностью сольётся. А сольётся настолько, что такая организация потеряет профит уже через неделю. Можно пойти ещё дальше и разделить сеть на N сетей для каждого адреса.

Кросстранзакции возможны. И для этого достаточно иметь только 2 цепочки блоков, вместо всего объема данных. После проведения транзакции имеется возможность безболезненно удалить вторую цепочку. Замечу, что данное решение по безопасности совпадает с хранением и верификацией транзакций в обычном блокчейне, но при этом не требуется хранить весь блокчейн на ноде.

Совсем иная ситуация со смартконтрактами. В них подавляющее число операций завязано на смартконтракт и они могут быть реализованы в рамках одной цепочки блоков.

[ftrmsltcsrp]

Кросстранзакции возможны. И для этого достаточно иметь только 2 цепочки блоков, вместо всего объема данных.

Надо определиться уже как действовать - по схеме текущей, либо нет.

После проведения транзакции имеется возможность безболезненно удалить вторую цепочку.

Сейчас можно итак безболезненно удалить всё, но как я уже выше писал - надо определиться со схемой.


Если остаётся такая же схема верификации как есть - т.е. каждая нода должна мочь полностью верифицировать цепочку, то любой кроссперевов требует миграции всей цепочки из сети а в сеть б. И есть два пути - вера в то, что цепочка валидна, либо выкачивать её из другой сети. Но опять же это невозможно в архитектуре текущей сети, ибо мы можем получить быстро предыдущую транзакции, но не можем получить блок, в которой эта самая транзакция живёт. Тем самым как и сейчас нам потребуется выкачивать весь блокчейн.

Замечу, что данное решение по безопасности совпадает с хранением и верификацией транзакций в обычном блокчейне, но при этом не требуется хранить весь блокчейн на ноде.

Это невозможно по определению в рамках текущей архитектуры. Причины я написал выше.

[Vitalik Kuliev]

Тем самым как и сейчас нам потребуется выкачивать весь блокчейн.

Видимо мы говорим о разных уровнях безопасности.

В сети будут майнеры которые будут содержать весь блокгрид или только его часть. Они будут заниматься генерированием блоков. Проверить есть ли у ноды определенный блок просто -достаточно скачать его и проверить хеш и наличие заголовка в цепочке заголовков и суперблоков. Суперблоки и заголовки блоков занимают совсем немного места в сравнении со всем блокгридом и будут храниться на каждой ноде.

Для проверки одной транзакции достаточно полной цепочки блоков, которая относится к этой транзакции, а также список блоков со входящими транзакциями, чтобы убедиться о наличии баланса. Данный метод позволяет на 100% убедиться, что транзакция верна, без необходимости выкачивать данные всего блокгрида. Это реальная альтернатива SPV для кошельков юзеров, которые имеют ограниченное число транзакций.

[ftrmsltcsrp]

Проверить есть ли у ноды определенный блок просто -достаточно скачать его и проверить хеш и наличие заголовка в цепочке заголовков и суперблоков.

Дело не в том, чтобы проверить - дело в том, чтобы локально верифицировать цепочку. По транзакции блок не получишь.

Суперблоки и заголовки блоков занимают совсем немного места в сравнении со всем блокгридом и будут храниться на каждой ноде.

Ещё раз. Все блоки хранятся на каждой наде только лишь для того, чтобы можно было верифицировать локально любую цепочку. Я уже 10раз это повторил. Выкинуть их можно хоть сейчас.

Для проверки одной транзакции достаточно полной цепочки блоков, которая относится к этой транзакции, а также список блоков со входящими транзакциями, чтобы убедиться о наличии баланса.

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

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

Какой метод? Я задал конкретный вопрос. Как в рамках архитектуры текущей сети получить по входящей тхид блок, в котором эта транзакция лежит? Без ответа на этот вопрос все рассуждения о 100% и прочем не имеют смысла.

[Vitalik Kuliev]

Какой метод? Я задал конкретный вопрос. Как в рамках архитектуры текущей сети получить по входящей тхид блок, в котором эта транзакция лежит? Без ответа на этот вопрос все рассуждения о 100% и прочем не имеют смысла.

Задачи поиска транзакции по txid не существует. Есть задача верификации транзакции с учетом данных(inputs, otputs, signature...). Из самой транзакции получаем публичный ключ и связанный с ним адрес кошелька. По этим данным выбираем цепочку блоков с которой связан этот кошелек. Выкачав эту цепочку найдем все транзакции с этого адреса и убедимся, что деньги еще не были потрачены.

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

[ftrmsltcsrp]

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

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

Для того, чтобы убедиться, что входящие средства есть на кошельке нужно скачать блоки, содержащие эти транзакции.

Зачем мне повторять какую-то околесицу? У нас ситуация, что из А следует Б. Я говорю о том, что А не может существовать и ответа на причины ПОЧЕМУ она существовать может я не получил. Зачем мне рассказывать про Б не доказав возможность существования А?



Если попроще. Легенда: "Вася вендурвафлей замочит Петю". Я спрашиваю "откуда Вася возьмёт эту вундервафлю?", а мне в ответ "ну он возьмёт и стрельнет в петю, а того расщепит на молекулы".

[Vitalik Kuliev]

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

Об этом детально в документе описано.

1) Исходящие транзакции важны в первую очередь, чтобы избежать двойной траты. Все исходящие транзакции привязаны к конкретной цепочке блоков. Чтобы их получить нужно выкачать эту цепочку.
2) Входящие транзакции нужны лишь только для того, чтобы убедиться в наличии средств на адресе. Их можно получить, скачав блоки с входящими транзакциями. Список блоков можно получить с полной ноды.

[ftrmsltcsrp]

В целом всё ясно и уровень понимания и владения темой то же.

1) Исходящие транзакции важны в первую очередь, чтобы избежать двойной траты. Все исходящие транзакции привязаны к конкретной цепочке блоков. Чтобы их получить нужно выкачать эту цепочку.

Это просто невероятно. Зачем мне повторят то, что итак ясно и то, что я уже 10раз сказал? Меня не интересует то, что для проверки транзакций нужны блоки и другие невнятные рассуждения. Мне нужен ответ на вопрос "Каким образом эти КОНКРЕТНЫЕ блоки можно получить в рамках текущей архитектуры сети?".

Всё остальное меня интересует, все выводы из того, что блоки уже есть и описание того что с ними можно сделать не работают пока не доказана возможность получить эти блоки. Где в сети есть механизм, который позволяет получить конкретные блоки по их содержимому?

2) Входящие транзакции нужны лишь только для того, чтобы убедиться в наличии средств на адресе. Их можно получить, скачав блоки с входящими транзакциями. Список блоков можно получить с полной ноды.

Ещё раз. Скачать - это не ответ. Это расписка в полной некомпетентности. Я спрашиваю не о фантазиях, не об рассуждениях на тему этих фантазий, а о конкретных механизмах которые позволяют это сделать. Это разве так сложно понять?

[Vitalik Kuliev]

Теперь понял в чем был основной вопрос. Блоки будут скачиваться с других нод точно также, как в обычном блокчейне. Для понимания на какой ноде есть конкретный блок будет специальный запрос, который возвращает список битовых масок цепочек, имеющихся на ноде.

Для равномерного распределения нагрузки для скачивания будет выбираться ближайшая нода. Расстояние между нодами задается по XOR метрике, аналогично тому, как это делается в Kademlia.

[ftrmsltcsrp]

Теперь понял в чем был основной вопрос. Блоки будут скачиваться с других нод точно также, как в обычном блокчейне. Для понимания на какой ноде есть конкретный блок будет специальный запрос, который возвращает список битовых масок цепочек, имеющихся на ноде.

Для равномерного распределения нагрузки для скачивания будет выбираться ближайшая нода. Расстояние между нодами задается по XOR метрике, аналогично тому, как это делается в Kademlia.

А можно меня пощадить? Я уже не знаю что делать. Нихрена не понял.


Все проблемы уйдут когда люди научатся отвечать на вопросы прямо. Я задал конкретный вопрос "описание механизма пожалуйста?" мне в ответ какая-то билиберда и "как в биткоине". Конкретный механизм того, как можно получить из ид входа в тразакции блок с телом входной транзакции. Не скачать неведомо что, ни "как в биткоине", а конкретно. Тогда все проблемы уйдут.



Ещё раз. Проблема не в том, чтобы скачать какой-то конкретный блок. Проблема в том, чтобы узнать какой именно блок. Есть ид предыдущей транзакции и надо получить блок в котором она лежит.

[Vitalik Kuliev]

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

Прямой ответ - механизм "получения транзакции по ее ид" в системе блокгрид отсутствует. Архитектура разрабатывалась, чтобы эффективно решать типичные задачи под высокой нагрузкой:
- обработка большого количества транзакций
- 100% верификация конкретной транзакции
- многочисленные операции над смартконтрактом

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

[ftrmsltcsrp]

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

Прямой ответ - механизм "получения транзакции по ее ид" в системе блокгрид отсутствует. Архитектура разрабатывалась, чтобы эффективно решать типичные задачи под высокой нагрузкой:
- обработка большого количества транзакций
- 100% верификация конкретной транзакции
- многочисленные операции над смартконтрактом

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

Не, я знал конечно что форумные эксперты это иллита, но чтобы до такой степени. Все ваши попытки не более чем бред, где все выводы основаны на незнании и не понимании. Я уже 20раз объяснял почему
"100% верификация конкретной транзакции" невозможна при ваше "архитектуре".

А теперь ещё раз, у нас есть n-сетей с кросстранзакциями и у нас есть клон только нашей сети одно(допустим 5) из n. К нам приходит транзакция из сети 7. Для того, чтобы верифицировать транзакцию нам надо получить блки из сети 7, ибо у нас их нет. В транзакции у нас есть только ид входа и никаких ссылок на блок нет. Т.е. в конечном итоге нам надо "Если вам нужно найти транзакцию по ее ид, то поднимаете полную ноду" - да, нам надо скачать "полную ноду" сети 7. И далее нам пришло из сети 11, а потом 15, потом мы отправили в сеть 9, а потом и в 12 итаким образом сеть сольётся.


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

[Vitalik Kuliev]

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

"100% верификация конкретной транзакции" невозможна при ваше "архитектуре".

Почему невозможна 100% верификация ОДНОЙ конкретной транзакции без загрузки всего блокгрида?

[ftrmsltcsrp]

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

"100% верификация конкретной транзакции" невозможна при ваше "архитектуре".

Почему невозможна 100% верификация ОДНОЙ конкретной транзакции без загрузки всего блокгрида?

Ну это просто какой-то невероятный аутизм. Мне уже это надоело. Каких всех? Что ты несёшь? Какое ещё подтверждение? Я уже могу констатировать только запущенную стадию скудоумия. Опять же зачем мне пихать какие-то ущербанские термины? Они меня не интересуют.



Ни о каких подтверждениях речи не шло - речь шла об локальной верификации. Верификация невозможна без клона сети - финиш. Все попытки как-то юлить и выкатывать какую-то херню сравнивая его с текущей сетью смысла не имеют, ибо на ноде(хоть они и мастер потенциально, но мастер-нод в биткоине кроме пуллов не существует, ибо они не жизнеспособны - т.е. подавляющие большинство нод клиентские) клон сети лежит не для работы сети, а для локальной верификации. Если мы выпиливаем локальную верификацию( а без неё все эти потуги не жизнеспособны и не работают, пусть это и следствие тотального невладения темой, либо запущенного скудоумия) из "суперновой сети", то это уже не улучшенный эквивалент - это просто другое. Таким макаром можно просто выпилить локальную верификацию и получить тонкий клиент, которых и сейчас навалом.




По поводу "почему" - уже 10раз всё объяснил. Для верификации транзакции со входом из другой сети нужны блоки, которых нету на текущей ноде, которая из другой сети и "блокчейн" у неё есть только её родной сети. Соответственно для верификации входа нужен "блокчейн" другой сети в которой находится эта входящая транзакция. Финиш. Нам нужен клон "блокчейна" другой сети.


Проблема так же решается вводом "идекснод" совмещённых/отдельных, но опять же это стоит не дюжих вычислительных ресурсов, которые клиентские и не клиенсткие ноды дарить никому не будут. И опять же проблемы с верификацией - нельзя удостоверится в валидности блока не пройдя по цепочке, которой естественно у нас нет. И это опять же будет не верификация в полной мере.


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


Ну и по поводу "подтверждений" подтверждения требуют такой же верификации, поэтому опять же те же самый проблемы.




В конечном итоге - если человек не понимает базовых основ работы сети, то что он тут делает и что предлагает? Если он не может внятно отвечать на вопросы - что он тут делает? Да и просто подумать не в состоянии. Зачем я каждый раз повторяю одно и то же?

[Vitalik Kuliev]

По поводу "почему" - уже 10раз всё объяснил. Для верификации транзакции со входом из другой сети нужны блоки, которых нету на текущей ноде, которая из другой сети и "блокчейн" у неё есть только её родной сети. Соответственно для верификации входа нужен "блокчейн" другой сети в которой находится эта входящая транзакция. Финиш. Нам нужен клон "блокчейна" другой сети.

В том то и дело, что нам нужны несколько блоков из другой сети, но никак не целый блокчейн! Эти несколько блоков уже проверены другой полной нодой, которая выпустила суперблок, и нам дополнительно не нужно этот блок полностью верифицировать. Есть проблема того, что полная нода могла считерить, и выпустить невалидный блок. Ее можно решить штрафом для этой ноды, аналогично тому, как было описано в "ethereum muave paper".

Вокруг НЕ необходимости загрузки соседнего блокчейна ведется обсуждение. Есть аргументы доказывающие некорректность верификации транзакции?

ftrmsltcsrp, прошу не реагировать так эмоционально. В любом случае благодарю за участие в обсуждении 

[ftrmsltcsrp]

Ну я уже не знаю как это комментировать. Я не хочу никого обижать, но тут попахивает не менее чем диагнозом.


"В том то и дело, что нам нужны несколько блоков из другой сети, но никак не целый блокчейн!" - это Б, при этом начальные условия у нас "ид входящих транзакций", т.е. А - это выделение конкретных блоков. Я уже 20раз спрашивал про механизм, который позволяет выделить те блоки в которых лежат тела транзакций из множества. В рамках текущей архитектуры сети этого сделать невозможно.

Эти несколько блоков уже проверены другой полной нодой, которая выпустила суперблок, и нам дополнительно не нужно этот блок полностью верифицировать.

На это уже был дан заранее ответ. Биткоин определяет всех как мастернод и верификация локальная предполагается. Майнил кто-то или не майнил - это не важно - блок верифецировать без всего "Блокчейна" нельзя по определению.


Если же мы убираем локальную верификацию, то никакое хранение клона "блокчейна" на ноде ненужно и все "новые куллсети от экспертов" не имеют смысла по умолчанию.

Вокруг НЕ необходимости загрузки соседнего блокчейна ведется обсуждение. Есть аргументы доказывающие некорректность верификации транзакции?

Что? Было уже написано 10раз попытки являются не рабочими. И про корректность блоков и прочее.



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



"Человек" уже лет с 3-х может понять,  что если у нас есть нечто, то нечто должно откуда-то взяться, чтобы с ним можно было что-то сделать. Нельзя жрать конфеты, которых нет. Да даже птушник-домушник понимает, что он не может выкрасть из хаты нечто конкретное не идентифицировав себе цель по её содержимому. Он понимает, что между "бомбануть нужны хаты" и множеством хат в хебаре есть часть "идентификации целей". Т.е. ему надо либо спросить у подельников(у сети, но как мы выяснили сеть это не умеет), либо обследовать каждую хату. Других вариантов нету.

[ftrmsltcsrp]

По поводу "почему" - уже 10раз всё объяснил. Для верификации транзакции со входом из другой сети нужны блоки, которых нету на текущей ноде, которая из другой сети и "блокчейн" у неё есть только её родной сети. Соответственно для верификации входа нужен "блокчейн" другой сети в которой находится эта входящая транзакция. Финиш. Нам нужен клон "блокчейна" другой сети.

В том то и дело, что нам нужны несколько блоков из другой сети, но никак не целый блокчейн! Эти несколько блоков уже проверены другой полной нодой, которая выпустила суперблок, и нам дополнительно не нужно этот блок полностью верифицировать. Есть проблема того, что полная нода могла считерить, и выпустить невалидный блок. Ее можно решить штрафом для этой ноды, аналогично тому, как было описано в "ethereum muave paper".

Вокруг НЕ необходимости загрузки соседнего блокчейна ведется обсуждение. Есть аргументы доказывающие некорректность верификации транзакции?

ftrmsltcsrp, прошу не реагировать так эмоционально. В любом случае благодарю за участие в обсуждении 

Ещё раз попроще. Список нужных транзакций находится в нескольких блоках, но не всех. Для верификации транзакции нужны не все блоки. Но между этой задачей стоит другая задача - получить нужны блоки, где в условии задачи у нас есть только айдишники транзакций. Т.е. по эти самым айдишниками нужно узнать какие конкретно блоки нам нужны, а уже далее их получить.


И проблема заключается в том, что именно для решения этой задачи нужны либо все блоки локально, либо какой-нибудь индекс(локальный), либо возможности сети(индекс удалённый). Как мы уже выяснили сеть этого предоставить не может и остаётся только локальное решение задачи. Т.е. для решения задачи нужен весь "блокчейн", либо его индекс.

[Vitalik Kuliev]

И проблема заключается в том, что именно для решения этой задачи нужны либо все блоки локально, либо какой-нибудь индекс(локальный), либо возможности сети(индекс удалённый). Как мы уже выяснили сеть этого предоставить не может и остаётся только локальное решение задачи. Т.е. для решения задачи нужен весь "блокчейн", либо его индекс.

Собственно ты сам и ответил на свой вопрос. Каждая нода содержит индекс своей цепочки блоков. Для того чтобы получить список нужных блоков нужно обратиться к ноде у которой есть этот индекс и получить список нужных блоков. Для этого не нужен весь блокгрид.