Zcash to sieć kryptowalut oparta na proof-of-work, a ZEC jest jej natywnym aktywem. Obsługuje przejrzystą aktywność oraz chronione transfery, które mogą ukrywać wybrane szczegóły transakcji, gdy używane są kompatybilne portfele i pule adresów.
Użyj tej strony, aby ocenić, czy Zcash spełnia potrzeby płatnicze lub prywatnościowe, a następnie sprawdź kompatybilność odbiorcy, aktualne opłaty, politykę potwierdzeń oraz ograniczenia chronionej aktywności.
Ta strona jest edukacyjnym odniesieniem do sieci i rynku. Nie gwarantuje prywatności transakcji, kompatybilności portfeli, wsparcia giełd ani wyników inwestycyjnych.
ZEC/USDT · Binance Spot · UTC
Długie zakresy automatycznie używają kompatybilnego interwału świec.
Historyczne świece Binance Spot są dostępne. JavaScript jest wymagany do aktualizacji bieżącej świecy.
| Czas (UTC) | Otwarcie (USDT) | Najwyższy (USDT) | Najniższy (USDT) | Zamknięcie (USDT) | Wolumen (ZEC) |
|---|---|---|---|---|---|
| 25 sie 2026 11:00:00 UTC | 842,37 USDT | 843,75 USDT | 833,55 USDT | 836,27 USDT | 6 207,88 ZEC |
| 25 sie 2026 10:00:00 UTC | 839,73 USDT | 846,44 USDT | 835,81 USDT | 842,39 USDT | 8 168,63 ZEC |
| 25 sie 2026 09:00:00 UTC | 842,23 USDT | 854,97 USDT | 837,28 USDT | 839,61 USDT | 9 525,32 ZEC |
| 25 sie 2026 08:00:00 UTC | 852,56 USDT | 855,53 USDT | 840,66 USDT | 842,23 USDT | 9 848,26 ZEC |
| 25 sie 2026 07:00:00 UTC | 851,55 USDT | 866,93 USDT | 846,71 USDT | 852,50 USDT | 13 269,04 ZEC |
Dane rynkowe: Binance Spot ZEC/USDT
Biblioteka wykresów: TradingView Lightweight Charts
Zcash obsługuje zarówno przejrzyste, jak i chronione przepływy transakcji.
Protokół obsługujący chronione transakcje nie czyni każdej transakcji ZEC prywatną.
Zcash jest użyteczny tylko wtedy, gdy wybrany portfel, odbiorca i ścieżka transakcji wspierają prywatność i kompatybilność, których faktycznie potrzebujesz.
Opcjonalne chronione transfery, płatności z zachowaniem prywatności lub selektywne ujawnianie są istotne, a każdy uczestnik używa kompatybilnego oprogramowania Zcash.
Posiadanie ZEC lub korzystanie z sieci Zcash nie ukrywa automatycznie transferu. Pula źródłowa, odbiorca docelowy i ścieżka utworzona przez portfel decydują o tym, co jest chronione.
Portfele, giełdy i usługi płatnicze obsługują różne typy odbiorców i pule. Prawidłowy adres Zcash może być nadal bezużyteczny w konkretnym przepływie usługi.
Zweryfikuj typ odbiorcy, wsparcie portfela, wybraną ścieżkę transakcji, wyświetloną opłatę oraz politykę potwierdzeń usługi odbiorcy przed autoryzacją płatności.
Jeden ZEC równa się 100 000 000 zatoshis; precyzja wyświetlania w portfelu nie zmienia podstawowej kwoty.
Podstawowa jednostka rozliczeniowa widoczna dla portfela
Najmniejsza jednostka rozliczeniowa ZEC
Zatoshi stanowią całkowitoliczbową jednostkę rozliczeniową używaną, gdy oprogramowanie reprezentuje kwoty i opłaty ZEC. Sam nominał nie ujawnia, czy wartość jest przechowywana w puli transparentnej czy chronionej.
0,01 ZEC równa się 1 000 000 zatoshis.
Nominał kwoty jest oddzielony od tego, czy transfer korzysta z puli transparentnej czy chronionej.
Opłaty transakcyjne Zcash są płacone w ZEC i reprezentowane w zatoshi. Obecne konwencjonalne wytyczne dotyczące opłat wykorzystują logiczną pracę wykonaną przez transakcję, a nie jedną uniwersalną stałą opłatę dla każdego transferu.
Zgodnie z obowiązującą zasadą konwencjonalnych opłat ZIP 317, portfele liczą akcje logiczne wniesione przez przezroczyste wejścia i wyjścia oraz przez osłonięte wydatki i wyjścia. Opłata krańcowa w wysokości 5 000 zatoshis jest stosowana z dwoma akcjami ulgowymi, co utrzymuje minimalną konwencjonalną transakcję na poziomie 10 000 zatoshis, jednocześnie pozwalając, aby bardziej złożone konstrukcje kosztowały więcej.
Konstrukcja transakcji chronionej może obejmować dopełnienie w celu zmniejszenia wycieku informacji z nietypowych kształtów. To dopełnienie i aktywność między pulami mogą wpływać na liczbę działań, więc dwie płatności o tej samej kwocie ZEC mogą otrzymać różne opłaty obliczone przez portfel. Opłata konwencjonalna jest wytyczną polityki portfela, a nie twierdzeniem, że konsensus wymaga, aby każda transakcja używała jednej dokładnej opłaty.
Minimalna transakcja w ramach dwóch akcji ulgowych ma konwencjonalną opłatę w wysokości 10 000 zatoshis, co odpowiada 0,0001 ZEC. Transakcja z większą liczbą akcji logicznych może mieć wyższe zalecenie.
Użyj opłaty pokazanej przez aktualny, zaufany portfel. Nie koduj na stałe starszego założenia o stałej opłacie ani ręcznie nie wybieraj nietypowej opłaty bez zrozumienia jej wpływu na prywatność i przekazywanie.
Transakcja Zcash może łączyć transparentne wejścia lub wyjścia z chronionymi działaniami Sapling lub Orchard. Wynikowa prywatność zależy od pełnej ścieżki wybranej przez portfel.
Transparentna aktywność ujawnia swoje publiczne adresy i wartości. Chronienie przenosi wartość z transparentnego źródła do chronionej puli; odsłanianie ujawnia transparentną stronę docelową; a w pełni chroniony transfer chroni odpowiednie chronione adresy i pola kwot przed zwykłą publiczną inspekcją. Transakcje między pulami mogą obejmować więcej niż jeden protokół transferu, więc portfel musi wyjaśnić, co jest chronione, zamiast traktować każdą transakcję z dowodem jako równoważną.
Noty źródłowe, odbiorniki docelowe, obsługa reszty i wsparcie portfela określają, które transparentne lub chronione komponenty są konstruowane.
Dowód wiedzy zerowej weryfikuje chronione komponenty bez ujawniania ich chronionych wartości, ale nie ukrywa przezroczystych komponentów ani metadanych zebranych poza protokołem.
Zcash obsługuje przezroczystych, Sapling i Orchard odbiorców. Ujednolicony adres może kodować wielu odbiorców, aby portfel wysyłający mógł wybrać najlepiej obsługiwany protokół transferu.
| Typ adresu | Typowy prefiks | Pula | Typowe zastosowanie | Uwaga dotycząca zgodności |
|---|---|---|---|---|
| Przezroczysty odbiorca | t1 lub t3 | Przezroczysty | Publiczne transfery i szeroka integracja z przestarzałymi systemami | Adresy i przesyłane wartości są publiczne |
| Odbiorca Sapling | zs | Pula chroniona Sapling | Chronione płatności w kompatybilnych portfelach | Bezpośrednie wsparcie Sapling różni się w zależności od portfela i usługi |
| Odbiorca Orchard | Wewnątrz ujednoliconego adresu | Pula chroniona Orchard | Aktualne chronione płatności przez kompatybilne portfele | Brak samodzielnego kodowania adresu Orchard dla użytkownika |
| Ujednolicony adres | u | Kontener odbiorców | Jedno kodowanie adresu, które może przenosić obsługiwane typy odbiorców | Portfel wysyłający wybiera kompatybilnego odbiorcę; prywatność nie jest gwarantowana |
Ujednolicony adres jest kontenerem adresów, a nie dowodem, że końcowa transakcja jest chroniona. Nadawca dekoduje dostępnych odbiorców i wybiera tego, którego obsługuje; polityka portfela i usługa odbiorcy pozostają zatem częścią wyniku prywatności. Klucze podglądu to oddzielne wrażliwe poświadczenia, które mogą ujawniać chronioną aktywność w celach księgowych lub selektywnego ujawniania bez przyznawania uprawnień do wydawania.
Potwierdź, którego odbiorcę użyje portfel wysyłający, zwłaszcza gdy ujednolicony adres zawiera więcej niż jedną opcję.
Portfel lub giełda może obsługiwać przezroczyste depozyty, ale nie Sapling, Orchard lub każdą formę ujednoliconego adresu.
Pierwsze potwierdzenie rejestruje transakcję w zaakceptowanym bloku. Dodatkowa głębokość zmniejsza ryzyko reorganizacji zgodnie z polityką portfela lub usługi, ale nie zmienia prywatności transakcji już ustalonej przez jej ścieżkę.
Transakcja jest widziana przez portfel lub usługę, ale nie jest jeszcze uwzględniona w zaakceptowanym bloku.
Transakcja jest uwzględniona w jednym zaakceptowanym bloku Zcash, podczas gdy ryzyko reorganizacji pozostaje zależne od polityki.
Każdy późniejszy zaakceptowany blok sprawia, że reorganizacja jest mniej prawdopodobna; wymagana głębokość różni się w zależności od portfela, sprzedawcy i giełdy.
Portfel może czekać na skonfigurowane potwierdzenia lub warunki zaufania, zanim pozwoli na wydanie otrzymanego wyjścia.
Portfel może wyświetlić przychodzącą kwotę, zanim uzna to wyjście za możliwe do wydania. Rozróżnienie zależy od uwzględnienia w bloku, głębokości potwierdzenia, tego, czy portfel traktuje źródło jako zaufane, oraz własnej polityki ryzyka. Oficjalne wytyczne portfela mogą zalecać próg potwierdzeń, ale to zalecenie jest polityką operacyjną, a nie pojedynczą regułą konsensusu dla każdego sprzedawcy, giełdy i portfela.
Interfejsy powinny odróżniać wykrytą płatność od potwierdzonego, zatwierdzonego polityką salda, które można wydać.
Głębokość potwierdzenia dotyczy ryzyka odwrócenia. Wybór odbiorcy i ścieżki transakcji dotyczy ujawnienia.
Dwukierunkowy projekt zachowuje znane publiczne zachowanie płatności, jednocześnie zapewniając silniejszą poufność w łańcuchu dzięki protokołom chronionym.
Transparentna aktywność Zcash zachowuje się podobnie jak konwencjonalna płatność UTXO: adresy i przesyłane wartości są widoczne w publicznym łańcuchu. To ułatwia podstawową inspekcję, depozyty giełdowe i integracje dla usług opartych na publicznych rekordach transakcji. Oznacza to również, że te transfery nie otrzymują ochrony adresu i kwoty w pełni chronionej ścieżki.
Chronione pule umożliwiają węzłom weryfikację ważności transakcji bez publikowania chronionych pól nadawcy, odbiorcy i kwoty w ten sam sposób. Zmienia to to, czego zwykły obserwator łańcucha może się dowiedzieć, ale nie usuwa istnienia transakcji, jej opłaty ani wszystkich wskazówek tworzonych przez czas, kontrahentów i otaczający przepływ pracy.
Wspieranie obu modeli pomaga Zcash współdziałać z oprogramowaniem o różnych możliwościach, ale przenosi ważną decyzję do portfela. Portfel musi rozpoznać odbiorcę, wybrać obsługiwany protokół transferu i wyjaśnić, kiedy wartość przechodzi między pulami transparentnymi i chronionymi. Znany ekran wysyłki nie wystarczy, jeśli ukrywa, która ścieżka zostanie użyta.
Przydatne dopasowanie zależy od celowego wsparcia chronionego, wykonalnej ścieżki odbiorcy i polityki operacyjnej, która akceptuje specyficzne dla Zcash kontrole zgodności.
Zcash może pasować, gdy obie strony celowo obsługują chronionego odbiorcę, a nadawca może zweryfikować ścieżkę przed podpisaniem.
Uwaga na: Potwierdź wersję portfela, typ odbiorcy, opłatę i wsparcie odbiorcy; przejście na aktywność transparentną zmienia model ujawniania.
Możliwości przeglądania mogą wspierać uzgadnianie lub raportowanie bez przekazywania uprawnień do wydawania, gdy przepływ pracy jest zaprojektowany w tym celu.
Uwaga na: Określ, kto otrzymuje dostęp do przeglądania, co on ujawnia i jak materiały kluczy są przechowywane i odwoływane operacyjnie.
Aplikacja może dobrze korzystać z Zcash, gdy jawnie obsługuje Unified Addresses, chronionych odbiorców, opłaty i stany potwierdzeń.
Uwaga na: Przetestuj każdą obsługiwaną pulę i ścieżkę migracji, zamiast zakładać, że ogólne wsparcie portfela kryptowalut jest wystarczające.
Wsparcie dla chronionych odbiorców i komponentów Unified Address różni się w zależności od usług, więc ścieżka chroniąca prywatność może nie być dostępna wszędzie.
Porównaj: Użyj toru płatności jawnie obsługiwanego przez każdego wymaganego kontrahenta, a następnie porównaj jego kompromisy w zakresie ujawniania.
Zcash umożliwia aktywność transparentną i mieszane przejścia między pulami. Protokół nie może zamienić nieobsługiwanego odbiorcy lub transparentnego celu w w pełni chronioną płatność.
Porównaj: Oceń projekty z domyślną prywatnością, jeśli opcjonalny wybór ścieżki jest nie do przyjęcia, jednocześnie przeglądając ich własne ograniczenia zgodności.
Ta strona opisuje Zcash jako sieć płatności i prywatności, a nie jako substytut ogólnego środowiska aplikacji w stylu EVM.
Porównaj: Oceń platformę inteligentnych kontraktów, gdy programowalny stan aplikacji jest centralnym wymaganiem.
Chronione protokoły chronią określone pola w łańcuchu; nie są obietnicą całkowitej anonimowości operacyjnej.
W chronionym transferze protokół ma na celu utrzymanie chronionych adresów i wartości przed zwykłą publiczną inspekcją, jednocześnie umożliwiając sieci odrzucanie nieprawidłowych wydatków. Transparentne wejścia i wyjścia pozostają publiczne, a przenoszenie wartości do lub z chronionej puli może ujawnić transparentną stronę tej ścieżki. Prywatność zależy zatem od całej transakcji, a nie tylko od tego, czy pojawia się w niej jeden chroniony odbiorca.
Zachowanie portfela ma znaczenie, ponieważ portfel wybiera noty, odbiorców, obsługę reszty i protokoły transferu. Unified Address może zawierać więcej niż jeden typ odbiorcy, a portfel wysyłający wybiera ten, który obsługuje. Poprawia to kompatybilność, ale nie gwarantuje, że końcowa płatność użyje chronionego odbiorcy Orchard lub Sapling.
Klucze przeglądania zapewniają kontrolowany dostęp do odczytu bez przyznawania uprawnień do wydawania. Mogą wspierać księgowość, raportowanie lub selektywne ujawnianie, gdy portfel i proces biznesowy obsługują je poprawnie. Należy je nadal chronić jako wrażliwe informacje, ponieważ posiadacz może poznać szczegóły transakcji, które nie są publiczne w łańcuchu.
Prywatność sieci nie ukrywa również informacji zbieranych gdzie indziej. Giełda, sprzedawca lub kontrahent może znać tożsamość konta, adres IP, szczegóły dostawy lub zależności czasowe. Więcej potwierdzeń może zmniejszyć ryzyko odwrócenia, ale nie ukrywa informacji już widocznych w transparentnej ścieżce lub już udostępnionych usłudze.
Użyteczne rozróżnienie nie polega na tym, która sieć jest uniwersalnie lepsza, ale czy transparentność, opcjonalne chronienie lub domyślna prywatność odpowiadają zamierzonemu przepływowi pracy.
| Sieć | Model transakcji | Zachowanie adresu | Konsensus | Typowe dopasowanie | Kompromis operacyjny |
|---|---|---|---|---|---|
| Zcash | Ścieżki transparentne, osłaniające, osłonięte i odsłonięte współistnieją. | Transparentne, Sapling i Orchard odbiorniki mogą być reprezentowane przez kompatybilne formaty adresów, w tym Unified Addresses. | Dowód pracy. | Przepływy pracy, które celowo wybierają wsparcie osłonięte lub selektywne ujawnianie. | Kompatybilność odbiornika, puli i usługi musi być sprawdzona. |
| Bitcoin | Wejścia i wyjścia transakcji są publicznie sprawdzalne. | Formaty adresów identyfikują obsługiwane miejsca docelowe skryptów, a nie osłoniętą pulę. | Dowód pracy. | Szeroko obsługiwane publiczne płatności i rozliczenia UTXO. | Publiczny graf transakcji wymaga oddzielnych praktyk prywatności. |
| Monero | Funkcje prywatności protokołu stosują się do zwykłych transferów domyślnie. | Adresowanie portfela jest zbudowane wokół prywatnego zachowania transakcji, a nie opcjonalnych transparentnych odbiorników. | Dowód pracy. | Użytkownicy, którzy chcą zachowania prywatności bez wybierania transparentnej lub osłoniętej ścieżki. | Wsparcie usług, metody audytu i narzędzia operacyjne różnią się od transparentnych systemów UTXO. |
Większość błędów wynika z traktowania możliwości sieci jako automatycznej właściwości każdego portfela, adresu i transakcji.
Korekta: Zcash obsługuje ścieżki transparentne i osłonięte. Tylko pola chronione przez wybrane osłonięte protokoły transferu otrzymują te właściwości poufności w łańcuchu.
Dlaczego to ważne: Transparentny nadawca lub odbiorca może ujawnić adresy i wartości, których nie można później ukryć, czekając na więcej bloków.
Korekta: Unified Address jest kontenerem dla kompatybilnych typów odbiorników. Portfel wysyłający wybiera odbiornik, który obsługuje, zgodnie z obowiązującym standardem i jego możliwościami.
Dlaczego to ważne: Ostateczna ścieżka może się różnić w zależności od portfela, więc nadawca musi zweryfikować wyświetlany odbiornik i wynik prywatności.
Korekta: Potwierdzenia zwiększają głębokość po włączeniu do bloku i zmniejszają ryzyko reorganizacji zgodnie z polityką. Nie przepisują wcześniej ujawnionych danych transakcji.
Dlaczego to ważne: Bezpieczeństwo przed odwróceniem i poufność to oddzielne właściwości i wymagają oddzielnych kontroli.
Korekta: Wsparcie różni się w zależności od produktu, wersji i polityki usługi. Odbiornik ważny w ramach protokołu może być nadal odrzucony przez konkretny interfejs.
Dlaczego to ważne: Przepływy wysyłania lub depozytów powinny być testowane przed transferem wrażliwym na czas lub o wysokiej wartości.
Korekta: Obecne wytyczne dotyczące konwencjonalnych opłat uwzględniają działania logiczne i obejmują działania grace. Portfele mogą obliczać różne konwencjonalne opłaty dla różnie skonstruowanych transakcji.
Dlaczego to ważne: Na stałe zapisana stara płaska kwota może zaniżać opłatę wybraną przez portfel i może tworzyć nietypowe zachowanie opłat.
Korekta: Osłonięte protokoły chronią zdefiniowane pola w łańcuchu, a nie informacje zbierane przez urządzenia, sieci, giełdy, sprzedawców lub kontrahentów.
Dlaczego to ważne: Prywatność operacyjna nadal zależy od połączeń portfela, tożsamości konta, czasu i tego, co jest udostępniane poza łańcuchem.
Praktyczne kontrole różnią się dla osoby dokonującej jednej płatności, zespołu portfela, usługi przyjmującej depozyty lub organizacji używającej selektywnego ujawniania.
Przed wysłaniem zidentyfikuj, czy miejsce docelowe jest transparentne, Sapling, Orchard czy Unified Address i przeczytaj podgląd portfela dla rzeczywistej ścieżki transferu. Samo saldo ZEC nie mówi nic o wsparciu odbiornika ani o tym, co transakcja ujawni.
Portfel powinien analizować aktualne formaty adresów, poprawnie wybierać odbiorców, obliczać aktualną konwencjonalną opłatę i rozróżniać otrzymane od wydawalnych sald. Komunikaty błędów powinny wyjaśniać nieobsługiwane ścieżki zamiast po cichu przechodzić do trybu awaryjnego.
Usługi powinny określać, jakie typy odbiorców akceptują, czy mogą zwracać środki na shielded cel i ile potwierdzeń wymaga ich własna polityka ryzyka. Operacje depozytowe potrzebują również ścieżki odzyskiwania dla nieobsługiwanych adresów lub opóźnionej wydawalności.
Selektywne ujawnianie może wspierać uzgadnianie lub raportowanie bez przyznawania uprawnień do wydawania, ale materiał do podglądu może ujawniać posiadaczowi chronioną aktywność. Procedury dostępu, przechowywania, przekazywania i incydentów powinny być zdefiniowane przed jego udostępnieniem.
Migawka to zagregowane dane CoinGecko ZEC/USD. Wykres to dane Binance Spot ZEC/USDT. USD i USDT to różne aktywa kwotowane, więc wyświetlane wartości mogą się różnić.
Podstawowe standardy techniczne użyte do przeglądu transakcji, odbiorcy, opłat i wyjaśnień dotyczących portfela na tej stronie.
Dodatkowe pytania operacyjne, na które nie odpowiadają główne sekcje dotyczące transakcji i odbiorcy.
Klucze podglądu mogą zapewnić dostęp do odczytu do obsługiwanej aktywności chronionej, bez przyznawania możliwości wydawania środków. Organizacja nadal potrzebuje polityki dotyczącej dostępu, przechowywania oraz dokładnego zakresu ujawniania informacji.
Portfel może wykryć transakcję przychodzącą, zanim osiągnie ona wymaganą głębokość potwierdzeń lub politykę zaufania niezbędną do wydatkowania środków. Interfejs powinien rozróżniać salda wykryte, potwierdzone i dostępne do wydatkowania.
To zależy od zawartości Unified Address i portfela wysyłającego. Portfel może wybrać obsługiwany odbiornik transparentny, jeśli jest obecny, ale nadawca musi zweryfikować wyświetlaną ścieżkę, ponieważ ten wybór zmienia to, co jest publiczne.
Zweryfikowana treść techniczna, przejrzane źródła i historia aktualizacji.