OK, spróbujmy. vProg to jakby to maleńkie środowisko EVM, którego stan jest całkowicie zakodowany na warstwie bazowej, więc nie potrzebuje żadnych rollupów powyżej. Ma to wiele zalet i wad. Główna zaleta: brak rollupu, wszystko na warstwie bazowej, kompozycja staje się "trywialna". Główna wada: brak rollupu, cała dostępność danych spoczywa na użytkownikach, a kompozycja staje się kosztowna na dużych skalach czasowych. vProgi mają sens w sytuacjach, gdzie atomowa kompozycyjność jest szybka (czas potrzebny na wygenerowanie dowodu jest porównywalny z opóźnieniem sieci) i częsta. Rollupy mają sens, gdy chcesz operacji długozasięgowych z ciągłą dostępnością danych. Ponadto, vProgi nie sprawdzą się w żadnym kontekście, gdzie wymagana jest zewnętrzna płynność. vProgi nie zastępują rollupów, one je uzupełniają. W szczególności, vProgi mogą być potencjalnie używane w skryptach blokujących rollup (część, która określa warunki, na jakich zablokowane aktywa, np. Kaspa zmostkowane do rollupu, mogą być odblokowane), aby przynieść korzyści obu. Ale głównie, nikt dokładnie nie wie, czym są vProgi, w tym osoby, które je obecnie projektują, ponieważ taka jest natura pomysłów, które wciąż się rozwijają. Atomowa kompozycyjność vProgów może być kluczem do kanonicznej interoperacyjności rollupów. Myślę, że to prawdziwa moc tej koncepcji i motywacja stojąca za nią.