Сергей Субботин

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

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

В статье есть, помимо прочего, расчёт расстояния пробега до столкновения, поэтому, не заостряя внимание на самих формулах, приведу общий план итерации симулятора (для реализации описанного ниже плана потребуется позаимствовать процедуры определения дистанции свободного пробега до столкновения и вычисления векторов скоростей после соударения):

1. просчитать предварительное новое положение каждого из шаров (прибавить ∆t *V_i к текущим координатам каждого i-го шара), и в случае наложения «предсказанных» шариков вычислить для каждого пробег ДО касания (я буду использовать значение доли λ_ij от ∆t (шага симуляции);
   доля шага симуляции (лямбда) — это значение от 0 (почти столкнулись на предыдущем шаге моделирования) до 1 (ещё чуть-чуть, и столкновения на этом шаге бы не было совсем));
    
2. отсортировать пары шаров по полученным значениям долей, чтобы рассматривать сначала те столкновения, которые случились раньше;
    
3. для очередной пары столкнувшихся рассчитать
    
   (а) положения в момент касания (t+∆t*λ_ij),
    
   (б) векторы скоростей (см. статью по ссылке выше),
    
   (в) положения на момент t+∆t (к положениям в момент касания добавить значение вектора скорости после соударения, умноженное на ∆t*(1−λ_ij), корректируя таким образом положение пары на момент t+∆t с учётом столкновения;
    
4. повторять цикл для всех пар шаров, заново определяя наложения после каждого уточнения и начиная расчёт уточнений сначала (для коллизий с самым маленьким значением λ)
    
5. если больше коллизий среди набора предсказанных положений для t+∆t нет, значит, кхм, we could call it a step.

Разумеется, это всё ещё далеко не Virtual pool, но визуально, особенно для моделей с грубым шагом симуляции, это обеспечит ощутимо бóльшую точность. Разумеется, такие заморочки нужны только если таковая нужна. Если нет — из статьи выше достаточно позаимствовать формулы для расчёта углов отскока.

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

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

1. Девайс не вывозит подобные вычисления

Что за древний девайс? Или... Сколько у вас шагов, сколько требуемая точность?

Ещё возможные проблемы: вы не правильно выписали уравнения, либо не правильно применяете метод Рунге-Кутты. Например, вместо радиуса в квадрате, в обычной форме уравнений должен быть радиус в кубе, а так как радиус вычисляется через корень, то получится корень в кубе.

Эллипс можно посчитать только для двух тел. Для трёх тел там уже не эллипс.
Эллипс / гиперболу / параболу по двум телам и их начальным условиям (позиция, скорость, масса) можно найти как посчитать на английской версии википедии на странице Kepler orbit.
Но это уже зубодробительная геометрия. И сделать всё это правильно и точно - это задача не из лёгких. Я как-то хотел это проделать, потом плюнул. А ведь просто хотел добавить "прогнозируемую" траекторию тела во время его добавления в симуляцию.
Если быть точнее, вот в эту: https://github.com/HermannBjorgvin/Gravity-Experiments

Метод Рунге-Кутты может быть не только четвёртого порядка, но и выше. Чем выше порядок тем выше и точность.

Точки Лагранжа можно найти и на эллипсах скорее всего, только там надо либо самому их найти, либо найти литературу где это описано.

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

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